We don't use inbound mail so I can't advise you there but if you check out this guide it covers basic Process Design
I'm assuming that an incident is created from an email and the subject line in the email becomes the title field in the incident (that's a guess) so you might have 1 decision to see how the incident was created and if it was from an email (true) then it moves to another decision to see what the title field contains and then moves to an assignment to the relevant group or whatever.
Not having used inbound mail this is all guess work as to how the incident is actually created but I'd say the above guide is where to start.
1 of 1 people found this helpful
In addition to what has already been mentioned, the way we have a (very basic) form of this setup is using conditions and assignments at the beginning of one of our process designs.
In this process we have a condition that checks to see if the incident category has been set yet (among others), which is a simple yes/no check.
If the answer is yes, then the call proceeds normally to our default 'In Progress' status. On the otherhand, if the check comes back as no then we know it's a call that's been logged externally to our department, such as by email or via the customer portal, for example. This will then be followed by an assigment, which can be created to send the call to whichever group you specify.
So for example:
Is title 'Delete Document'? Y/N
N - Continues onwards to the next condition in the chain
Y - Is assigned to the group you specified that handles these requests instead (via an assignment).
Is title 'Delete File'? Y/N
N - Continues onwards to the next condition (or to your default group/status)
Y - Is assigned to the group you specified that handles file deletions (again, via an assignment).
Take a look at the screen shot below, this shows the beginning of our incident process, it's fairly simple but it does show the category check I mentioned near the top, and also, a few other conditions; so you can see how these checks are done in sequence and flow from one to the other.
It's fairly simple once you have a play around with it.
I'm not sure how many conditions you can have in a chain, (I think there is a limit) but I'm sure someone here will know - it depsnds how many different calls you're planning to check for, if there's quite a few then something with calculations may be needed, to keep the process design from starting to look like a piece of modern art.
I hope this helps a little.
I believe this restriction has been removed from 7.3.x onwards.