Part 4 – Creating the Incident via the Remedy Email Engine

Back here I started this whole overview on automating Remedy using the Remedy Email Engine.  Part 2 and Part 3 followed.

Here in Part 4 we are going to get to the meat of it.  Up to this point we have done all the work necessary to get emails into our system and into our custom email processing form.

So now what?

Creating an Incident from an Email

Now we are at the best part – creating a new Incident.  Since we’ve already processed/formatted everything this part is very straight forward.  Examine this image:

One of my most major complaints about Remedy is that you can not open the field mappings box to see more than a few lines….that said…the mappings in this case are very simple.

In previous versions of BMC Remedy Help Desk you would simply push the value to the form.  With the advent of BMC Remedy Incident Management you can no longer do it.  Well, you CAN do it – it’s just not very fun.  Instead, we are going to use the built-in interface for creating Incidents.  The advantage here is the number of fields we need to map is quite minimal.

In short, we are pushing from our current processing form to the HPD:IncidentInterface_Create form.  The mappings are as follow:

• Status – New (List value)
• Description – $Subject$ (email subject line)
• Assigned Support Organization = “My Organization” (a valid support organization – you can hold this in your configuration form and do multiples if you want to get fancy)
• Last Name – “Caller” (Static value in my case due to unpredictable callers.  This could easily be looked up and configured to a real/existing person’s information)
• First Name – “Unknown” (Static value in my case due to unpredictable callers.  This could easily be looked up and configured to a real/existing person’s information)
• z1D_Action – CREATE (Mandatory field value to create an Incident)
• Service Type – User Service Restoration (List value)
• Detailed Description – This one gets complicated.  There are carriage returns inserted below everywhere you see a & sign.  I had to replace them to make everything happy on the web:  (((((((((((( “To: ” + $To:$) +  ” & “) +  “From: “) + $From:$) +  ” &”) +  “Date: “) + $Create Date$) +  ” &”) +  “Subject: “) + $Subject:$) +  ” &”) +  “Message:”) + $Message Body$
• Urgency – 4-Low (List value)
• Impact – 4-Minor/Localized (List value)
• Reported Source – Email (List value)
• Assigned Group – “Support” (Configuration value or static depending on your needs)
• Assigned Support Company – “My Company” (The appropriate company to go with the support group)

When this push fields happens an Incident is created – and that’s it.  In our case the agent then goes on to examine the email and respond to the customer appropriately.  The agent may also update the Caller/Contact information with a real caller.  They can do this either by selecting an existing one or creating a new profile for the caller.

If this is done the caller will even get updates to the Incident via email (if configured correctly).  This brings up to our next concern – how do we update Incidents via email?  That is in part 5.