6 Replies Latest reply on Jan 10, 2018 2:36 PM by Randy Powell

    Is it possible to generate tickets created by email listener as Service request instead of incident?

    Kelvin Santana
      Share This:

      We are currently able to create incidents by sending an email to our email listener but I wanted to know if it is possible to generate the ticket as a service request instead of an incident?


      See below for example of test email I sent. Note, system generated the ticket and entered information I specified in fields such as Category, Source, etc.



      This is a test.


      Category## Primavera Contract Management##


      TicketType##Service Request##

      RequestDefinition##PCM Project Creation##

      Impact##3 LOW##

      Urgency##3 LOW##

        • 2. Re: Is it possible to generate tickets created by email listener as Service request instead of incident?
          Randy Powell

          I did this.  My email comes in with key information for me to drive process builder...


          Text request definition = 'Request access'   ---> update record Request definition = ID XXXXXX1

          Text request definition = 'Request laptop'   ---> update record Request definition = ID XXXXXX2

          Text request definition = 'Request cell phone'   ---> update record Request definition = ID XXXXXX3




          It is converting the incident into a request like it should, but it is not filling out fields that would typically come from user in self-service.


          Example: in request cell phone, they give their desk phone number.  That field is mapped in self-service to description.  In the email template we tell them to put their desk phone number in the description and it maps to the description field in the record.


          ISSUE: in the request details section on the console, the desk phone number is blank (even though the description is filled out).  Not a huge issue except that since it is required, you can not update the ticket unless you go down and fill out the desk phone number.


          Can I map the request details fields via process builder or have it done automatically?

          • 3. Re: Is it possible to generate tickets created by email listener as Service request instead of incident?
            kedar zavar

            This is the challenge as  the forms are dynamic and no mapping option like this. How to read  email  to input fields mapping. Some one will have to type answers (agents) and save. Ideally Self service should be used (promote self service adoption ) and you can also send direct link to forms if using SSO and my domain so user can just launch form .


            What you did is step one like this https://forceadmins.com/2017/02/26/creating-service-request-via-email/ however mapping would be tough  and woudl be idea -  we need new listener /feature for mapping.


            We definitely want uses to use Self service as this will get uses away from SS adoption.



            • 4. Re: Is it possible to generate tickets created by email listener as Service request instead of incident?
              Randy Powell

              I am not providing access to the users, but for staff, they are sometimes quicker to adopt an email than logging into the system.


              I am trying to stop the drive-by request that come from the users.  I have staff send (based on template that I gave them) an email to open the request for them.  It takes seconds and gets them "permission" to fulfill the request.  It is just causing a delay once they go back in to close the ticket.


              I am also using this for Standard RFC.  The process builder creates a change request that is linked to the emailed incident ...now..request...It works well opening and managing the change request, but once the request needs to be closed, it causes the same issues with having to back fill in the request fields.


              It seems like I could do an update record or create record for the request details in the process builder that passes the information for those fields.


              SR.description --> SR_details.SS_Details_description field

              • 5. Re: Is it possible to generate tickets created by email listener as Service request instead of incident?
                John Wisdom

                Hi Randy


                Being able to generate a service request from an email would be very beneficial. Our primary use case is in regards to move requests. When an associate is moving from one space to another (could be same building or different building) they submit the request through a site Corporate Facilities uses as they coordinate the moves and update the maps, etc.. If there is a computer hardware component to the move then the associate has to fill out a second request in Remedyforce Self Service.


                The Corporate Facilities solution has the ability to generate an email on submission. It is configurable and I would like to be able to leverage the  email listener so the SR in Remedyforce will be automatically generated. Saving our associates from having to duplicate work is always a good thing.


                We would also use this solution for requests that are generated as a result of work that comes out of our identity management tool.


                I wonder if we need to put an Idea out here for this?



                • 6. Re: Is it possible to generate tickets created by email listener as Service request instead of incident?
                  Randy Powell

                  I was able to work around it.


                  I was able to create them in two ways (both worked pretty well)


                  1) I submitted the email request with the field request definition mapped to a field in the email.

                       This worked well as it mapped the request to the request type.  The only issue is that my request definition names are not easy to remember.

                  2) I submitted the email request with the a field service request title (but you can use any field), then used process builder to act based on the data in this field.  The simplicity is I could use a key word like 'MOVE' in this approach and the users could remember it.


                  The challenge with both methods is identified above.

                  a) The fields that are inputs in the request definition (self-service) will be populated in the ticket (BUT BLANK).  That means a couple issues show up.  If any of those fields are required, then when you update the ticket via the console, You must populate those fields (and your staff may not know to go to the bottom to look).  In my case, my fields were called things like description which mapped to the actual description.  This confuses my staff when they are looking at a populated description field in the ticket and getting an error message saying 'Description field is required'.

                  b) If you have additional templates triggered in your request definition (self-service) then when those fields get populated in the ticket, they will trigger those templates.  (Example:  I have a request that triggers a RFC.  In the process builder, I created the change based on the email.  Then when my staff filled in the fields on the SR ticket, it created another RFC.  The same thing can happen for tasks.


                  What I have done is simple...but stupid...

                  1) Since once the ticket is created, we don't really care about the name of the request type, I created a dummy request type called 'E-mail Created Request' and it triggers workflows based off simple things like location, category, etc.

                  2) For request we care about the name in the request, I created a duplicate request called 'Email create <Real request type>' and deleted those input fields.


                  Works well.