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
