Part 3 – Backend Workflow used to Automate Incident Creation via the Remedy Email Engine

Part one covers the overall general concept and big picture considerations.

Part two covers technical considerations dealing with AR Server type, email protocols, and similar concerns.

This post will cover the first (and easiest) portion of the coding – namely, getting the email into a temporary processing form where we can process it.

There is a basic assumption for this post: You have already created an incoming email address for the Remedy Email Engine to access.  You have also determined the protocol it uses (MAPI, POP3, etc) and tested the connection to make sure the Remedy Email Engine connects and retrieves the messages and puts them into the ”AR System Email Messages” form.  This is all pretty straight forward stuff.

Creating the Processing Form

Before anything else is done a temporary form must be created for processing the emails.  We could process emails using filters attached to the “AR System Email Messages” form but that would be customizing base product code which I try to avoid at all costs.  It’s simply not worth it.  Instead, I create a custom form to do the processing and attach one filter to the “AR System Email Messages” form to push the data over.  We’ll get to that filter later – first we need somewhere to PUT the data.

This is a pretty simple exercise.  First, we’ll just create a standard form.  I prefer to copy the BMC Remedy ITSM look and feel for my forms just to keep everything consistent.  This particular form might be accessed manually by an administrator from time to time so I added a nice consistent look and feel.  Then I added a page holder with three pages:

• Custom Email Fields
• Auto Populated Fields
• Core Fields

Custom Email Fields

On the Custom Email fields tab I added the fields in this screenshot:

Custom Email Fields tab

• To – The original “To” value from the email
• From: – The original “From” email address value
• Subject: – The original email subject
• Message Body: – The original email address
• Delete On: – Date to delete this message on automatically.  More on that later….
• System Matching Address: The address used in the system to validate the “To” field.
• Status: The status of this email.  Possible values include the following
  • New
  • Processed
  • Invalid

I’d like to make just a couple of quick notes on these. 

The “System Matching Address” is set via basic workflow and checks a configuration form.  All it does is a “Set Fields” action that says “Tell me what ‘To’ address is valid”.  This prevents internal spam.  If your company is XYZ company and the valid address is Support@XYXCompany you can add workflow to negate other addresses and mailing lists like AllEmployees@XYZCompany.  In those cases the email ‘Status’ is set to “Invalid” at this point so this email does not get processed and create an Incident.  You can of course make this work a number of different ways.

The ‘Status’ field is set to “New” when a record is created (Submit).  It is set to the value “Processed” when an email successfully creates an Incident.  It is set to “Invalid” when you code for internal spam as I explained above.

Auto Populated Email Fields

We also have a tab called “Auto Populated Email Fields”.  This contains the fields shown in this screenshot:

Auto Populated Fields

 These fields are necessary for the creation of the Incident using the HPD:IncidentInterface_Create form.  All of these values are necessary.  In my instance we had quite a few people contacting us who were unknown – we did not have Customer (People) records created for them in the Person form.  Nor could we predict the Support Company, Organization, or the appropriate assigned group.

Fortunately there is a very easy solution to this – and you could do something similar.  I created a configuration data form that held the default values for these.  They were different per server since our development server used different values than our production server.  

A sample of the values that I put into this form were:

• First Name: Unknown
• Last Name: Caller
• Support Company: My Company
• Support Organization: My Organization
• Assigned Group: Support

“Unknown Caller” was an actual Person record in the system.

These are static values and of course you could easily add workflow at this point to look up the Person record based on the “From” email address.  That would be a cleaner solution for most organizations if their callers are known.  If you are often creating new customer profile (Person) records the solution I used may work for you – after all, once the Incident is created the agent merely has to read the detailed description for the Incident and Create/Select the appropriate person record.  This is far less work that manually creating the Incident.

Core Fields

The Core Fields tab is self explanatory – the Regular Form core fields are parked here.  I rarely use the core fields for a variety of reasons but you’ll notice in this case I did use ‘Status’ on another tab.  The rest are defaulted to standard values.  I’ll leave that at that:

Remedy Core Fields

Workflow on the AR System Email Messages Form

There are actually two things we do with incoming email messages – for now we’ll simply cover a “Create” situation where an email comes in and we want to create a new Incident.

In this case the “Run if” is blank – we push all incoming messages to our processing form.  It’s easier to process them there.

There’s also a more important reason to not have a “Run If” when pushing from the “AR System Email Messages” form.  The Java process that runs the email engine will fail to create an entry in the “AR System Email Messages” form if the “Run If” fails.  So, it’s better to insure the messages come in correctly and then deal with them in another place.

So, the workflow to push to our processing form is pretty straightforward:

Push from AR System Email Messages

As you can see this simply pushes messages into the processing form.  From there the workflow I mentioned before sets the “Auto Populated Fields” values.

In the next installment I’ll cover the nuts and bolts of creating an Incident.  After that I’ll go over the trickier subject of updating