4 Replies Latest reply on Nov 6, 2017 4:29 AM by JulianWigman

    (LDSD 2017.1) Any creative ideas how to Allow Email relies but prevent New Incident creation from email

    tpratt Apprentice

      We're looking for any ideas how to open the ability for users to Reply to an incident via email but restrict Opening new incidents. We have an nice approach for adding Notes (we strip off the older content from within the email and only store the "new" part of a message as a note. However - we have a real need to have users visit the portal during Incident Creation (where we can prompt and hopefully guide input to avoid the generic "help - its broken" that we have seen when email is used to generate an incident.

       

      At first we thought it was simply a question of not mapping anything to the Incident detail (just map email replies to the Incident Note). However - what this does is to create a new Incident that has No Title and No Description (and then of course if you try and reference the incident in Web Desk it throws an error because of the missing data).. There appears to be nothing in the setup of the Email Box or Mapping definitions to control the process (i.e. prevent creation and only allow update.). In fact the documentation I believe details that LDSD looks for a reply indicator ("Re" by default but configurable") - and if found will look at the subject to match an incident number (and send an email to the user if it fails to match an incident). But - lacking any trigger that the email is a reply - it creates a new incident.

       

      The best approach I have thought of at this point is to look for additional text wither in the subject (ex - in addition to "Re" we always have Incident # 99999 in the reply email) or body. Then we could use the email gateway to filter the email prior to delivery to the LANDesk mailbox. This can work - but it is not ideal as if anyone ever "finds the trick" it will be common knowledge in minutes how to bypass the portal and submit by email (Hey Joe - just put Incident # in the subject and it opens a new incident for you!). I did try and get a little tricky since we use HTML mail (it's own flaw - but a different problem) and looked at 2 tricks. The first was to use the HTML5 tag "<p hidden>" - and stuff some magic text in the email that would be used as my key to allow the mail to pass thru the email gateway logic. That tag is not followed by my email client (Outlook 2016) - so I tried putting in a hidden form field (ex: <Input type=hidden name=magickey value=letmein>) but while most of the HTML and formatting is sent when people reply to of forward emails - the input field is dropped by these actions (so - my LDSD process sends this to the client - but the reply no longer has the form field.).

       

      Any other creative ideas? Extending the system to support email replies is a huge win for customer satisfaction; but not at the expense of a severe drop in the quality of the initial incident reporting. Maybe someone else has a creative idea? Too bad my process can't just "drop" the incidents that are created on the way in (really drop - like purge - not just close (they need to not exists or all of the metrics reporting starts to get messed up). Maybe there is some other method I can use to prevent the creation from occurring at all - that would be ideal.

       

      Thanks,

       

      Terry

        • 1. Re: (LDSD 2017.1) Any creative ideas how to Allow Email relies but prevent New Incident creation from email
          JulianWigman Master

          Simplest approach is to put a rule in exchange that moves any messages out of the inbox to another location as they arrive unless the subject line contains the “update” keyword you have defined.  Because the messages never touch the inbox unless they are updates then you wont create new lifecycles.

           

          I set my update keyword to “Update:” to ensure it ignores and “update” as normal text in the subject line.

           

          Julian

          MarXtar Ltd

          • 2. Re: (LDSD 2017.1) Any creative ideas how to Allow Email relies but prevent New Incident creation from email
            JulianWigman Master

            I should add the trick IMHO is that for every reminder you send out from the process to set the format of the summary to something like....

             

            ” Incident Update: {Id} - has blah blah blah ”

             

            ...via action instance data for the process reminder automatic actions; this way if they reply to the email in the email client as is human nature ( no matter how much we try to block) that at least these all have the requisite update keyword and ID to always update the lifecycle. 

             

            The “Subjects to ignore” section is really for blocking FW and Out-of-office IMHO and you can leave RE’s in place if you folllow the above of controlling the format of the outbound mail subjects in the first place.

             

            The exchange server rule then blocks the manual emails as per my previous post.

             

            Julian

            MarXtar Ltd

            • 3. Re: (LDSD 2017.1) Any creative ideas how to Allow Email relies but prevent New Incident creation from email
              tpratt Apprentice

              Thanks for the input. We can as you suggest (as does the question) use exchange to filter out any email that does not have the requisite keywords; simple enough and as you describe. What I'm trying to prevent is when the user community finds out that the keyword (either just a simple "Re" - or a more detailed string like "
              Incident Update: {Id}") can be used to open a New Incident.

               

              It at well be that the only path I have is the one we have described; and if/when the word get's out I 'll need to deal with it. As in my posting I was looking at methods to perhaps obscure the key from the users (hidden form field - or event the new hidden HTML tag - neither have panned out). I could as well intercept very quickly the incidents created via email and close them in the process (maybe a resolution that calls out that they need to use the portal or call the Service Desk to open an incident).

               

              Of course I'd like a solution that is a bit more user-proof; but given the value I believe we will receive by opening E-Mail Notes I may need to live with this.

               

              Again - thanks for the feedback! At least it is confirmation that the path we are looking at makes sense to at least someone else - flaws and all.

               

              Terry

              • 4. Re: (LDSD 2017.1) Any creative ideas how to Allow Email relies but prevent New Incident creation from email
                JulianWigman Master

                Directing users to use the Self Service Portal as their main UI is now a bad thing as a much richer experience than firing in an email.

                 

                So the idea of not allowing ANY creation by email is a sound move IMHO especially if you do have a bunch of users that are hackers from what you are saying.  If they are that switched on they should be able to solve problems themselves though without needing to log an Incident in the first place!!!

                 

                Julian

                MarXtar Ltd