10 Replies Latest reply on Jun 20, 2018 4:48 PM by vee

    Update field from incoming email

    ALandl Apprentice

      Hi, we have a 3rd party that emails "ticket created" notifications into our HEAT system. These emails attach onto our record using "Incident# <incident number>" in the subject. What I would like is for the incoming email to update our "3rd Party reference" field. Is this possible? The documentation hints at using the format <fieldname>$<fieldvalue> in the email body to do this, but I cannot seem to get this to work.

        • 1. Re: Update field from incoming email
          cw30755 Apprentice

          I have been asked if there is a way we can have failed jobs open an incident via email and the hope was that many of the fields could be already filled out with the pertinent info.  I think we've probably been looking at the same documentation and I'm a little confused too.


          I think we have to setup a new Inbox to allow this, but I am not sure if it can use the same email address as the basic listener or if it requires another address.  Below is a screenshot of how I think some of the screen should be configured.  Hopefully someone can come in and help fill in the figurative blanks.




          I would do some testing, but we just synched our environments to take an upgrade so I'll have to wait a few days to give this a whirl.

          • 2. Re: Update field from incoming email
            vee Specialist

            Should be possible if you are using XSLT processing.


            We do this but with an Insert, update may be different but here are some snippets of what we've done:


            <xsl:when test="contains($FromAddr,'3rd_PARTY_ADDRESS') and contains($Subject,'SUBJECT_OF_EMAIL')"> (this and is optional)

            <xsl:call-template name="3rd_party_new"/>



            Then in the 3rd_party_new.xsl file you can have something like this:


            <xsl:element name="Field">

            <xsl:attribute name="Name"><xsl:text>NAME_OF_FIELD</xsl:text></xsl:attribute>




            Is this what you were after? Happy to send you some of our work if you like.

            • 3. Re: Update field from incoming email
              cw30755 Apprentice

              Not OP, but I'll take any assistance you might be willing to offer.  I'm specifically looking for a solution that will allow some of our already automated jobs to send an email with various fields already populated that would create an incident.  We don't want to do away with the Self Service Email option, the basic one that just uses the email subject and body to generate a Logged incident.


              I know I don't have any of the OOTB XSLT processors turned on, but I think I need to add a listener or add an Inbox before I can do that.  That's where I get really confused.  Can I use the same listener as we use for our SSU emails, or do I need another email for that?  I am providing some screenshots of my setup, and again, I appreciate any insight you might be willing to offer.


              Listener Config:



              Data Import Connections (showing only XSLT, all OOTB):


              • 4. Re: Update field from incoming email
                vee Specialist

                So I've read somewhere here about people using more than one listener, but I have no experience with this. I do know however that you can't use the Self Service Email option AND XSLT at the same time (at least for the same listener), but you don't need to as you mimic what SSE did for you with XSTL but with a lot more flexibility. The downside of using XSLT is that it takes about 1-3 minutes to process an email sometimes. I really miss the instant processing of the OOTB method.


                I had a quick look at using multiple listeners. I had to add the "New" button to ours as it wasn't there OOTB. If you need to do the same, the BO is "TenantEmailMailbox#".


                I'm happy to share our XSLT work if you wanted to test if using a second listener will work for you.

                • 5. Re: Update field from incoming email
                  DTurner Expert

                  Hi vee,


                  Not OP, but if you wouldn't mind sharing your XSLT work, it would be greatly appreciated; coincidentally, I was actually testing a secondary listener early this week and XSLT is something I've wanted to look into but never played around with. If I had an example use case such as yours to look over, it would be great


                  Many Thanks


                  • 6. Re: Update field from incoming email
                    ALandl Apprentice

                    OP here. Thanks for all the feedback guys. I have been experimenting on setting up the XSLT import, since I have never used it before. I think I am almost there with it. I will let you know when I have a solution to my problem.

                    • 7. Re: Update field from incoming email
                      ALandl Apprentice

                      So I am having trouble getting a working XSLT file to do what I want. Using the "Incident_Update" template in Email Listener XSLT to update all objects I have been able to attach the email to the Incident number specified in the email subject, and also update some of the incident's fields to predefined values in the xslt.

                      However, I need to be able to have those fields updated to values that I put into the email itself.

                      Anyone more experienced with xslt that can help?

                      • 8. Re: Update field from incoming email
                        vee Specialist

                        Hey all, apologies for the delay in responding.


                        Forums will only allow me to upload up to 5 files so I picked the main ones.

                        I'm not the best person to explain entirely what's actually going on with these as I didn't write them myself, they were supplied by our vendor (cost us a grand, so enjoy ) but we have done a bit of tweaking and once you have a good look through them you'll see it's not too hard to make it work for you.


                        To use this, go to the Admin console - Integration Tools - Data Import Connections and look for "Email XSLT processing". It should already be there. Turn it on, and open it up.

                        The contents of "MainXSLT.xslt" is copy-pasted into the "Main XSLT" box, and then just upload the .xsl files and save:

                        Configure your mail box to use XSLT and you should be good to go:


                        An incoming email is checked against conditions set in this file to pick the correct .xsl file to use to process the email. There are two actions "Insert" or "Update". "Insert" creates a new ticket (Incident) and "Update" attaches the email to an existing ticket. (In this example, most of our conditions are for "Update" except for the last two) Most conditions are for update but if none of them match, the final condition is "Incident_New" to create a new incident.


                        1) For the most part we match emails on subject line. Because match statements are case sensitive, this line converts the email subject to all upper case: (this is only internally, it doesn't change the email itself once processed)

                        <xsl:variable name="Subject" select = "translate(BusinessObjectList/BusinessObject/EmailMessage/Subject,'abcdefghijklmnopqrstuvwqyz#','ABCDEFGHIJKLMNOPQRSTUVWXYZ#')"/>


                        So if you happen to receive an email with "InCIDent# 1234" it doesn't matter, it will still be translated to "INCIDENT# 1234"


                        2) After the translation, we run through all the "choose - when" conditions to find a match. If no matches are found, it uses the "otherwise - Incident_new" and creates a new Incident.


                        Example, if the email is received which relates to a record that already exists, it should have a subject line like: "Problem# 12345 - whatever". This subject is tested against the when conditions and this one will match:


                        <xsl:when test="contains($Subject,'PROBLEM#')">  "Problem# 12345 - whatever" is translated to "PROBLEM# 12345 - WHATEVER" so this condition is a match, and "Problem_Update" is run.

                        <xsl:call-template name="Problem_Update"/>




                        In this example the business wanted to process an email received from this system in a particular way. I duplicated the Incident_New.xsl file and added a few steps inside the .xsl so that the Service and Category is set:

                        <xsl:element name="Field">

                        <xsl:attribute name="Name"><xsl:text>Service</xsl:text></xsl:attribute>

                        <xsl:text>Corporate Applications</xsl:text>


                        <xsl:element name="Field">

                        <xsl:attribute name="Name"><xsl:text>Category</xsl:text></xsl:attribute>

                        <xsl:text>End-Point Security</xsl:text>



                        I look for this email specifically with the when condition looking for a from email address, and a specific subject line:

                        <xsl:when test="contains($FromEmail,'[email protected]') and contains($Subject,'SPLUNK ALERT: SOPHOS')">

                        <xsl:call-template name="Sophos_New"/>



                        For the most part you should be able to upload these files directly into your system and they should just work. Just have a look through Incident_New (and Sophos_New) as we did put some lines in there you might not want.


                        <xsl:element name="Field">

                        <xsl:attribute name="Name"><xsl:text>OwnerTeam</xsl:text></xsl:attribute> Sets the OwnerTeam to "Service Desk"

                        <xsl:text>Service Desk</xsl:text>


                        <xsl:element name="Field">

                        <xsl:attribute name="Name"><xsl:text>Source</xsl:text></xsl:attribute> Sets Source to "Email"



                        <xsl:element name="Field">

                        <xsl:element name="Field">

                        <xsl:attribute name="Name"><xsl:text>JournalDoNotEmail</xsl:text></xsl:attribute>  Sets a field we added "JournalDoNotEmail" to true. (We use this bool with a workflow to notify owners when email responses are received)




                        Hopefully this makes some sense? Let me know if you have any questions.

                        2 of 2 people found this helpful
                        • 9. Re: Update field from incoming email
                          cw30755 Apprentice

                          Wow, vee! Thank you SO much for posting this.  When I get some free time I plan on going through all of this with a fine-tooth comb and digesting each portion.  My first question is about the mailbox setup: did you setup a new mailbox / Inbox, or did you just change the processor on the default mailbox?


                          And can anyone answer if you can have both the default "Incident" processor as well as the XSLT processor, of does the XSLT processor just extend the functionality of the Incident email processor.

                          • 10. Re: Update field from incoming email
                            vee Specialist

                            No worries!


                            We changed the email processor type of our existing listener mailbox from Incident to XSLT. You can't run both at the same time on the same listener mailbox, but I believe you can configure a second listener. I'm testing this atm but having some issues with the form.

                            However yes, XSLT (if configured to do so) can have the same functionality as the Incident processor and more. We had to switch to it because from memory, the Incident processor was only able to ingest emails for Incident, ServiceReq and Approvals, for any other module it just logged a new Incident. We wanted emails for Problem, Change and other modules to also work so we had to go the XSLT way. One little thing we noticed with the Incident processor I think is worth mentioning: when someone replied to an approval vote with "approved" or "denied", the Incident processor checked if the approver was actually the person the vote was for. In other words if someone else replied to a vote with "approved" it wouldn't process. XSLT doesn't do this, if the vote number matches up and it sees "approved" it'll get processed. So technically anyone can approve any vote via email. I'm sure you can write some business rules on approvalvote to get around this, we just haven't bothered with that yet. All reply emails are attached to the vote so there is an audit trail if someone is being sneaky.