Video Screencast Help

Change to SD.Email.Monitor in 7.5 SP1 - "New Incident" no longer required

Created: 10 Dec 2013 | 7 comments
Lark's picture

This is something that had me scratching my head for a little and I thought I'd share it.

One of the new features in the ServiceDesk 7.5 SP1 release notes is "Ability to configure email monitoring projects to route based on multiple email inbox, thereby improving email monitoring"

This is great and looks like an excellent way to reduce the need to dabble in modifying the SD.Email.Monitor workflow.

A side effect of this is that by default, ALL e-mails sent to the monitored inbox result in a new incident being created.  Excluding those for existing tickets.  You no longer need to enter "New Incident" or "New Ticket" in the subject of the e-mail.

The SD.Email.Monitor workflow has had the "Is Email a New Incident Request" Embedded Rule Model removed.

The SD.Email.InboundManagement workflow now seems to never be triggered by default.  If you rely on this you might want to make sure you have a handy backup of your previous workflows and test test test!

Operating Systems:

Comments 7 CommentsJump to latest comment

jpellet2's picture

Anyone know if this is planned on being fixed? We noticed this recently when we started getting some LinkedIn invites as tickets! We do need to be able to go back and create tickets/set as junk rather than having everything become an incident.

TGiles's picture

Currently there are no plans to modify this behavior in a future release. The triggering of e-mail inbound management will now occur from inside SD.IncidentManagementSimple.

jpellet2's picture

Does this mean, then, that all emails will now become an incident, which is currently what's happening, or is there going to be a method to list something as junk before it ever becomes an incident?

TGiles's picture

All e-mails not classified as a reply to an incident or an Out of Office reply will generate an incident.

smassie's picture

The old helpdesk had the ability to specify a set of rules which would reject an email... So you could filter out most of the junk without a lot of work.

Some of my customers actually put a basic spam filter in place as well...

I don't like the need to have to put something in to specify this is a new ticket. It just puts unecessary hurdles in the way of end users which they don't like while it also relies on them a) remembering and b) typing correctly

Imagine if we had to put 'new email' into the header of every new email we sent out?

jgwolfpack's picture

I am also struggling to understand this new change in SP1. Right now any email coming into our inbox not only is created as a new incident (IM) but also has an EM created. You can classify the EM as junk but what is that really doing, the IM is already created and is not closed when the associated EM is classified as junk. Also one of the actions on an EM is to create an incident, why is this still there if an incident is automatically created.

Any help to understand this new process would be greatly appreciated.

TGiles's picture

By default in ServiceDesk 7.5 SP1 only e-mails that don't contain the words "New Incident" or "New Ticket" in their subject line will generate both an EM & IM ticket.  Those tickets that do contain these words are assigned to the Default Incident Queue based on the defined rule inside the OnIncidentReceived ruleset. The system uses the fact that the incident was generated by e-mail and it hasn't been assigned to a queue to determine that it needs to be routed to the Email Inbound Management project and create an EM ticket. When this happens the IM ticket has any existing tasks closed and goes into a pending state. Now inside Inbound Management if you determine that the generated EM ticket should be turned into an IM ticket the system will use the IM ticket that has already been generated and reactivate it putting it back into the process.

If you determine that the EM ticket is junk the EM ticket is closed. Now it was discovered after the release of SP1 that the associated IM ticket was being left in a pending state. An updated project for SD.EmailInboundManagement was released to address this issue and make sure that the associated IM ticket shows up as fully closed. You can find this updated project and all updates for ServiceDesk 7.5 SP1 in our Knowledge Base.