Workflow and ServiceDesk Community

ServiceDesk has the ability to process email messages and automatically generate incidents for technicians to work. This is very helpful in allowing end-users the ability to quickly send an email documenting a problem, and have a trouble ticket automatically created as a result.

In ServiceDesk 7.5, the email monitoring application is a user-editable process. This provides some flexibility to modify the project to accommodate specific needs.

Problems

One of the difficult things that users, especially those in larger environments experience is that incidents created from the Email Monitor program come in with no classification information or routing to specific service queues for proper handling. Some companies have taken a tactic of creating static classification or service queue mappings inside the monitor project. This works, however this still requires the technician to make further modifications to the incident to make sure the set information is correct. It also requires that the project must be modified if a change to these mappings is required.

Also, the ability to classify an incoming incident, based on the target email address, and to assign the email to a specific service queue does not exist in the out of box product, without some substantive customization.

Solution

In a two part series of articles, we will describe how this is done. The first article will explain how the ability to support multiple email boxes, from differing email host servers can be generated and maintained. The second article will outline how to configure the data mappings to accommodate classifying the incident and assigning to a Service Queue, based on the email address the message was sent to.

This article covers the configuration of the classification and service queue routing. You may use the following link to read the first article.

Expanding Servicedesk 7.5 - Part 1 - Monitoring Multiple Emails with a Single Email Monitor Application

The RoutingClassification.zip file attached to this article contains the three necessary files needed to make SD.Email.Monitor set the classification & service queue information for each incident it creates. The three files contained in the zip file are as follows:

1.  RoutingClassification.model: The model that contains all the components needed to make this modification. This model can be imported and left as a linked model, or if you prefer you can use its contents to simply create an embedded model inside SD.Email.Monitor.
2. Incoming_Email_Process.pfl - The application profile that was created to contain the names of the data mapping tables for routing and classification
3. ExportedDataMapping.xls - The definition file for the two data mapping tables created for classification & routing. These tables contain sample test data from my internal test server, so they will need to be updated to meet your environmental needs.

This completes the small overview. Lets move to getting it installed.

Installation and Configuration

Changes to the ServiceDesk Server

The Incoming_Email_processing.pfl & ExportedDataMapping.xls files need to be imported into the Process Manager portal before we make changes to the SD.Email.Monitor project.

Installing the Application Profile

1. Log into the Process Manager portal with an Administrator account.
2. Go to Admin->Data->Application Properties
3. Click on the Import Profile Definition button.
4. Click Choose File and select the Incoming_Email_Processing.pfl file
5. Click Import.

Installing the Data Mapping Tables

1. Log into the Process Manager portal with an Administrator account.
2. Go to Admin->Process Automation
3. Click on the Chevron next to Incident Management.
4. Click on the Service Dashboard button.
5. Click Manage Data Mapping
6. Click on the Import Data Mapping button.
7. Click Choose File and select the ExportedDataMapping.xls file
8. Click Import.

Once you've imported the data mappings you will need to make sure you update them to reflect the values that will be found in your environment.

As this modification was designed to be added to the SD.Email.Monitor-Multiple project the data mapping examples show the different e-mail addresses that are being monitored. Make sure that the information you supply in the data mapping match exactly the service queue names and the e-mail addresses. If they do not the mapping will fail in the project.

Please note that the model provided is only checking against a single key data mapping. If you wish to define both key1 & key2 values a slight modification will need to be made to the model. I'll explain that modification later when I go over the components in the model.

Modifying the SD.Email.Monitor-Multiple project

1. Open SD.Email.Monitor-Multiple project in Workflow Designer
2. In the Project view on the left right click on SD.Email.Monitor-Mulitple and choose Import Model
3. Select the RoutingClassification.model file and choose Open. If you wish to use an embedded model instead of a linked model see instructions under Using an embedded model, instead of a linked model.

4. Now open the ProcessMessage model and insert a Linked Model component between the 'Format Plain Text emails' & 'Submit Incident Ticket' components.

5. Open the Linked Model component and set the Component Model Name to Routing & Classification.
6. Set the Start Mapping as follows:
   1. Incident: Incident
   2. EmailMessage: EmailMessage
7. Set the Return Mapping as follows:
   1. Incident: Incident

Using an embedded model, instead of a linked model

1. Import the model as described above.
2. Open the newly imported model & copy all the components inside the model.
3. Now open the ProcessMessage model and insert an Embedded Model component between the 'Format Plain Text emails' & 'Submit Incident Ticket' components.

4. Right-click on the new model & choose Edit Component.
5. Click on the ellipses for Output data.
6. Click Add.
7. Create an output object called Incident with a Type IncidentTicket and click OK.
8. Click on the ellipses for Embedded Model.
9. Delete the default Start & End components.
10. Paste in the copied components from the imported model.
11. Double-click on the End component and confirm the Mapping for Incident is Incident.
12. Remove the imported model.

You are now ready to test the modified project.