8 Replies Latest reply on Nov 27, 2017 11:31 PM by Julian Wigman

    (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
          Julian Wigman ITSMMVPGroup

          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
            Julian Wigman ITSMMVPGroup

            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

              1 of 1 people found this helpful
              • 4. Re: (LDSD 2017.1) Any creative ideas how to Allow Email relies but prevent New Incident creation from email
                Julian Wigman ITSMMVPGroup

                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

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

                  Thanks for the info (sorry for delayed reply as I have been out of the office recovering from shoulder surgery).

                   

                  As I mentioned - the approach you detailed was one of our initial thoughts - not bullet proof but may do the job. We are running Exchange Online - and when we look at the rule set there does not appear to be an option to either:

                   

                  * And conditions together (since we need to use a server rule vs. client side rules - likely we need to identify the Recipient and the Subject to construct an appropriate rule.

                  * The Exchange rule sets do NOT have a negative conditions (ex: subject does not contain) - so dropping all email except where the keyword is found does not seem available.

                   

                  Do you have an example of how you were able to perform this function in Exchange? I assume that O365 (Exchange Online) has the same rules available as on-premis - but perhaps not.

                   

                  Thanks,

                   

                  Terry

                  • 6. Re: (LDSD 2017.1) Any creative ideas how to Allow Email relies but prevent New Incident creation from email
                    Julian Wigman ITSMMVPGroup

                    Sorry, not something I’m allowed to do, being an ITSM consultant, so the customers setup the exchange mailbox rules themselve outside of my involvement.

                     

                    Julian

                    MarXtar Ltd

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

                      Again - thanks for the shared information. As far as I can tell there is no method in Exchange Online to use a negative rule (ex - does not contain). The rule sets are pretty clear and limited (Mail flow rule conditions and exceptions (predicates) in Exchange Online: Exchange Online Help ) from what I have been able to research.

                       

                      Perhaps earlier versions allowed for the negative construct in the rule; but O365 documentation does not identify this ability. If anyone else has any creative ideas or supporting detail how to drop the email that does not contain the required response criteria I'm all ears. In the meantime I think we will look at a process based alternative that we were considering in addition to the Exchange rules:

                       

                      * Allow New incidents to be created (i.e. when the "Re:" or any other reply string we use is not found in the email subject LANDesk creates a new incident (this is the behavior we are looking to eliminate).

                      * In the process (1st action) we can put in a calculation to see if the Raised User is "System", the source is "Email" (set in a template), and the subject does not contain the key word (substring function that returns -1 (not found) looking at the email subject).

                      * The process can then send an email to the user stating that their incident has been closed automatically as New Incidents can't be created from email. The next step will be the same as a typical "close on creation" - a quick lived incident that is DOA.

                       

                      Not ideal (depending on volumes could spike SLA's) - but assume users will get used to the process (I suppose). I would love a more elegant approach - but nothing is coming to mind and the ability to ad notes via email reply is considered very high value by the user community and IT analysts.

                       

                      Thanks for all the input!

                      • 8. Re: (LDSD 2017.1) Any creative ideas how to Allow Email relies but prevent New Incident creation from email
                        Julian Wigman ITSMMVPGroup

                        OK so why not setup the mailbox linked to Service Desk to be a hidden mailbox ( not published to directory) and then set you outbound mail replies to go to a public facing mailbox.  Now you can use a “positive” rule to test for the UPDATE keyword and move these to the hidden mailbox to be processed as inbound mail and leave anything else unread in the public facing mailbox  (which someone will need to monitor).

                         

                        As I say I normally dont get involved with this as the customers Exchange Admins do this but for sure I know they did setup.

                         

                        Julian

                        MarXtar Ltd