9 Replies Latest reply on Apr 26, 2016 2:37 AM by joetetley

    Service Requests as emails

    joelwgray Rookie



      We currently have many folks who send in Service Requests as emails.  We have a service catalog but the adoption is still ramping up.


      Can anyone help with ideas on how you are handling emails that currently open incidents and converting into SRs?



        • 1. Re: Service Requests as emails
          dcogny Expert

          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.

          • 2. Re: Service Requests as emails
            fmosqueda Rookie

            Hi Joe, Daniel,

            We have a process for 'Incidents'. An email is sent to a mailbox of our choosing, email is received, processed, and incident opened! Settings below (email listener a must) Note: I use the HEAT Cloud, version 2015.2.2.13858. Hope this helps!



            • 3. Re: Service Requests as emails
              dcogny Expert

              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.

              • 4. Re: Service Requests as emails
                fmosqueda Rookie

                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.

                • 5. Re: Service Requests as emails
                  joetetley Apprentice

                  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!

                  1 of 1 people found this helpful
                  • 6. Re: Service Requests as emails
                    ben.prinsloo1 Apprentice

                    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.

                    • 7. Re: Service Requests as emails
                      sadams Rookie

                      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

                      • 8. Re: Service Requests as emails


                        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.

                        • 9. Re: Service Requests as emails
                          joetetley Apprentice

                          Hi Barry,


                          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!