Email Routing Made Easy w/ Postmaster
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-23-2014 07:52 PM
Routing inbound email is one of those things that should be easy in ServiceNow, but somehow it never is.
Any ServiceNow admin living in a world where email is still a means of ticket creation has had the same requests:
- "Can emails to 'fieldsecurity@acme.com' be routed directly to the Field Security group in ServiceNow?"
- "Can emails from 'event_generator@acme.com' be auto-categorized and automatically resolved?"
- "Can the emails to my group automatically generate catalog requests instead of incidents?"
These are all perfectly reasonable requests and, given how easy most things are in ServiceNow, they should be perfectly doable. However, spend a few hours navigating inbound email actions, debugging your javascript , checking for inbound actions conflicts, and (most fun) ensuring catalog items are generated correctly, and you shan't have much hair left. If you finally do get it right, you then have to schedule a change window to promote the new code from dev to test to production.
Stop the madness!
To sidestep all of this inconvenience, I built an app called Postmaster that takes the code out of email routing and brings configuration into point-and-click routing rules that can be added/edited/removed right in your production environment. This removes (most) human error from the equation and adds agility to the process of rolling out new email routing rules. This solution is something that I implement at every customer where I deploy ServiceNow, but could never distribute widely. Now, thanks to the magic of ServiceNow Share, I can share this with all of you!
Check out the demo video below to see how it works, and visit Postmaster Email Routing on Share if you'd like to try it out in your environment.
For the latest supported release, visit Postmaster Email Routing on the ServiceNow Store
Enjoy!
- Labels:
-
Multiple Versions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-22-2017 10:44 AM
I'm not unhappy just was a bit confused. I was able to interrogate the header information and find what I needed. We use the Postmaster a lot and like it as it is much improved over the native way of handling inbound emails.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-03-2017 12:45 PM
Hi Ben,
I have one point that needs clarification, Is the Postmaster supports tables that are only extended from Task??
Can we set up a postmaster rules to non-task extended tables?
Your views / response will be highly appreciated. Thanks.
-Durga.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-04-2017 07:06 AM
Hi Durga,
In the update set, we include a single Inbound Action on the task table that then interacts with Postmaster rules to generate records - so, OOB it just works with task-extended tables. However, you should be able to clone that Inbound action, set the table to whatever non-task table you need, and then use it that way. It would require a bit of extra work, but should be possible!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-10-2016 03:19 PM
Hello Ben
We are trying to add further inbound behaviours into Service Now, however we already have a number of inbound behaviours from the initial implementation which are working.
You mentioned in the video that the current behaviours will be de-activated, I just wanted to clarify whether we can added the PostMaster email routing rules as a addition in service now for new behaviours but leave the old behaviours that are currently from script working as they are currently working.
Kind regards
Sallie Worsley
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-10-2016 03:37 PM
Hey Sallie,
Postmaster basically just creates its own single Inbound Action that references the Postmaster rules table to figure out how to route a task. If you disable that rule, it is as if Postmaster was never installed. In a situation where you wish to use Postmaster *and* your existing Inbound Actions, you'll just want to ensure that the Postmaster Inbound Action is ordered to go first. If it iterates through the Postmaster rules and finds a match, that rule will run and all subsequent Inbound Actions will be ignored. However, if it iterates through all of the Postmaster rules and finds no matches, then ServiceNow will move on to your higher ordered Inbound Actions like before.
Long story short, there's no problem - you should be able to use Postmaster alongside your existing Inbound Actions with no problem. Just be sure to test prior to pushing to production to ensure that everything meets your needs and works correctly.