Routing Incidents Submitted by Email

Routing Incidents Submitted by Email

  • Comments 9
  • Likes

This question comes up fairly often – “How do I route incidents submitted by email?”  This usually has two variations:

1) Based on who is sending the email I need to route it differently.  For example, if the email is sent from Al Young I need to route the incident to a certain support team.  If the incident is sent from somebody else I need to route it to a different team.  There are other variations on this like: based on the user’s domain, based on the user’s office location, based on whether or not the user is a “VIP” – i.e. based on title, etc.

2) Based on which email address it was sent to I need to route it differently.  For example, if the email is sent to I need to route it to the printing team.  If it is sent to  it is a generic request and I need to route it into the general queue.

When emails are sent to Service Manager for processing they all end up on a SMTP drop folder and Service Manager processes them.  It doesn’t really matter who sends them or which email address they are sent to.  When the workflow processes each email it adds the To: address to the incident description like this:


It also looks up who the user is based on the From address and sets the affected user accordingly as you can see above.

So – now you can set up Incident Event Workflow rules in the standard way by doing the following:

1) Go to the Administration/Workflows/Configuration view.

2) Select the Incident Event Workflow Configuration row and clicking Properties in the task pane.

3) Click Add in the workflows list dialog.

4) In the wizard do the following:

a) click next on the welcome page (if it shows up)

b) provide a name, description (optional), select ‘when an incident is created’, and provide an MP.. click next

c) specify your criteria

To route/classify based on the To: address do this:


To route/classify based on information about the affected user (domain, title, company,”VIP” status,  etc) set up the criteria like this:


You could also route based on keywords in the email subject (ends up in the incident title) or message (ends up in incident description).

d) on the next screen choose a template which will route/classify the incident appropriately.

e) on the next screen you can optionally choose to send notifications to people related to the incident.

f) create and close and you’re done!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • I would like to to configure SCSM so that if automatically creates active incidents based on e-mails sent to I have followed the above instructions and have created a Incident related workflow.

    Is there any change that have to be made in order to allow SCSM to access specified incidents mailbox and fetch e-mails?



  • Damian - please follow the instructions here to configure email routing:

  • Can one delete incidents received on certain criteria? My SCSM recieves mail from a Backup System that I then convert into incidents based on the job status. What would be the best way to handle successfull jobs? Is there an option to Delete?

  • @Christo -

    Assuming there is a keyword that you can look for in the title or description like 'Successful' in this case, I would suggest:

    1) creating a template which changes the status to Resolved or Closed

    2) creating a new rule in the incident Event workflow that looks for these kinds of incidents based on the keyword that applies the template from #1 below when then incident is created.

    If you actually want to delete them you would need to use the Remove-SCSMObject from the smlets codeplex project in a custom workflow that you authored in the SCSM Authoring Tool.

  • How can this function work using Exchange Connector version 2? It no longer parses the TO: field into the description of the incident

  • @Robert -

    With EC 2.0 you would need to subscribe to incidents where the affected user's email address is xyz.  The EC 2.0 doesnt put the email address into the description field like the out of box workflow does.

    EC 3.0 is a much better deal.  You can set up multiple ECs.  Each EC can monitor a different mailbox and can have a different template configured for work item creates and updates.  EC 3.0 can create any type of work item from a template, not just an incident.  EC 3.0 is in private beta testing with TAP customers only right now but will be released publicly when the SCSM 2012 RC comes out publicly early next year.

  • EC3 sounds like the ticket!! Can't wait to use it and how can I get a copy of that to test in my environment???

  • Subscriptions won't work in our case as that would be an extensive list

    EC3 sounds like the answer with multiple ECs.


  • I installed EC 3 the problem is that it is not creating incidents out of the mails i send to my workflow mail box.  is there something special i have to do?