Actually, we have the same problem here; still not implemented, but our theoretically approach would be to create "orphan" Tasks from the emails and have an analyst to create and Incident or SR, depending the case and link the Task to that main call.
If you need a better explanation on this, let me know, I will expand it.
Thank you for the insight, but the problem is that we don't want to create Incidents after every email, as users are getting used to the Service Catalogue that is the right approach, but when you start there is a lot of users that will still use the email for Requests instead of Incidents.
OK. Did a little research and found this ....
About Creating Generic Business Objects from Email
This feature allows you to configure the HEAT email service to handle any generic business object except for service requests. You create an inbox for each business object type. So for example, all emails that are to create a task go to the task inbox, all emails that are to create a change go to the change inbox, etc.
1 of 1 people found this helpful
The issue is because Service Requests use templates and unless you do something clever with XML and XSLT or insist that users send the e-mail requests in a specific format, the processor won't know what template to log a Service Request against.
We currently have a button on the Incident which allows you to create a new Service Request from a template, links the Incident, then closes it. Further, I added a rollup relationship onto the journals tab of the Service Request so that the original e-mail from the now closed Incident can still be easily found by the person dealing with the request.
It's not ideal and still requires some manual intervention but it works for us at the current time.
Alternatively, refuse to accept Service Requests via e-mail or deal with them on a lower SLA, folks will soon get the message!
Question is, how do you expect this to work? As for your question, yes, you can create a SR via email using a dedicated email listener. However, you will lose the benefit of the Service catalog and related automation. The system won't be able to distinguish on the type of request just by looking at the body (unless you have it set as a fix format and use XSLT, but then the self service portal should be easier to use anyway), so it means the actual SR will need to be manually created/managed after the email created a generic request.
The downside is that users now will sit with two helpdesk emails to use, but at least the SR requests will be separate. If you go via the incident creation route, your helpdesk will then need to have a way to mark this as an SR, create the correct SR and link it to the Incident. All doable with some configuration. But I would suggest in both these cases an automated email should be sent to educate the user that the self service portal is available.
Thought I'd chime in... We had the same problem and discovered that originally HEAT didn't have separate modules for Incidents and Service Requests, and that the field to differentiate them still existed - it just wasn't in use anymore. We made the decision to stop using the Service Request module and moved both Incidents and Service requests to the Incident module with the field added back into our forms. This allows the analyst on duty to make the determination if the issue is an Incident or Service Request without having to create whole new tickets to move it to another module. The downside is that I had to recreate our Service Request templates as Incident templates and turn off access to the Service Catalog in the Self Service portal, but since we were never able to convince most of our users to use the Self Service portal it hasn't been an issue
The button you created on the incident form to create a SR, link it, close it. Is this something you can share on how you did this. We are looking to do the same thing here.
CSS originally wrote this for us and I've just doctored it. It only works for us because we are creating a very simple service request without parameters, I'm not too sure how you would pass parameters from the incident to the service request or if this would even be possible.
Basically, the button runs a composite Quick Action, the first part of which closes the incident and the second part of which creates the Service Request. The key parts below are the RecIDs for the template and subscription:
Hope this helps!