Automated Incident Creation through E-mails

One of the ways our company reports problems to our help desk is through e-mails generated from our customers. It alleviates the need to always call the help desk and talk to someone in person. When we implemented the Altiris Help Desk product, some of the functionality from our old system had to be reproduced in the new application. In addition to submitting tickets via e-mail, our users were used to submitting e-mails with unique subject lines that automatically routed help desk tickets to the appropriate IT support department.

There are many benefits to using this functionality. Such as, faster incident resolution by routing the tickets to the appropriate support group automatically. Customers are also freed up from having to call the help desk and wait for assistance and the chance of tickets being misrouted to the wrong queue by mistake are minimized. This process is very easy to achieve in the Altiris Help Desk system and here's how we did it.

First, you already need to have your e-mail inbox set up under the administrator menu. You will need this configured to process incoming e-mail messages and generate help desk incidents. Below is an example of how we've set up ours.

Click to view.

When you're through, be sure to test the connection to make sure it works. Also, if you're trying to have incidents created through e-mail (without the custom subject lines addressed in this article) simple have users submit help desk tickets to the account name. For example, in our case, customers can address the e-mails to "xpfiletest" or choose it from our Outlook distribution lists which have it also aliased to "HelpDesk". Either way, the system inbox configurations listed above, process the message from the Exchange account and generate incidents. In addition, a user can update an existing incident when the e-mail sent relates to an existing ticket. The inbox looks for unique characteristics, such as incident number, and updates the existing incident in the system. So, overall, having this inbox set up when using this system can be an invaluable resource.

If you need more information on setting up an e-mail inbox, refer to Helpdesk Solution 6.0 SP5 product guide. http://www.altiris.com/Support/Documentation.aspx (Page 117)

When creating many notification, routing, incident and validation rules, it's important to document information about the rule BEFORE creation. Change for change sake can make for a very complex and difficult environment to maintain. Also, when you go to make a change in the future, you might forget what other rules may be impacted by your one modification. So, we typically make a note of the following:

• Name of Person Requesting Change
• Purpose of Modification
• Process and Configuration for the Rule
• Which other rules effect this new process
• Where additional changes need to be made
• When/where to back up the current settings
• How/when this will need to be tested
• Potential risk assessments
• Name of Approving Manager

This ensures that everyone is on the same page and we've identified the reason for this modification. Often time, management will ask for a change and then not understand what the impact might be or how much work a particular change might require. It also reminds us what other rules may need exceptions added in or re-tested to make sure this change doesn't break something currently working.

Okay, so now that you've documented the purpose and expected functionality of your Routing Rule, let's create it. Under the Admin menu, choose Routing Rules and then New Routing Rule. When it comes to the name of your rule, we have some best practices. Make it understandable and distinctive from other names. When you're scanning the list in a hurry, it helps to recognize each one quickly without having to edit them. Using the comment field can work as a quick reminder of the rule's intention as well.

Click to view.

Initially, our goal was to maintain the current business processes using a unique name related to an enterprise system. So, we created a Routing Rule for each title. Above, we titled the rules using a naming convention of "UNIQUE NAME" Auto Routing. This helps us remember the purpose of your rules.

Now, some of the values you may choose when setting up routing rules will get you the same thing but in a different method. For example, if you choose to have the rule activate only when the ticket is first created your value under the "When" field is "Only when incident is new". This could also be accomplished by adding the criteria of version equaling the value of 1. Maybe you would want it to run repeatedly for anything titled Peoplesoft. Then you would choose the value of "Every time incident is saved" instead.

Here's how we configured our Peoplesoft routing rule.

Click to view.

The Route To field has the name of one of our existing IT support department queues. This has already been set up in the system. We configure our queues to notify an existing Exchange distribution list with membership pre-defined. This way, if an employee supporting our applications leaves our company or changes job responsibilities; we can easily managed this in Active Directory. We only want this rule to run the first time, so we restrict our values to "Only when incident is new". Since all of our e-mail generated tickets will be unassigned, we choose yes as the value of the "And unassigned" field.

We don't select "When the value of title changes" because this rule should only run when the title exists with the exact same name, not when it changes to the exact same name. That's why our only criteria is that the title of the incident equal "Peoplesoft" exactly. It's also very important to choose the "is the same as" option from the drop down listed below. We don't want this rule firing for someone submitting a ticket with the title containing the word we've identified as unique. This setting ensures that this rule will only process if the title matches that exact expression. Nothing more and nothing less. If you choose to make it case sensitive, be careful. It's very easy for customers to forget something like that and it might be less trouble to take the word in both upper and lower case.

Click to view.

This might seem like a lot of trouble to prevent the incident from being assigned to your queue accidentally. But without some of these precautions, the rule could behave in a way you didn't predict. Subsequently, rather than the individual worker being notified, the entire support team would. In some cases, our queues have both e-mail and pager notifications configured and all of these communications would've been unnecessary. So, it often pays off to give each rule some thought as to how it may be used unexpectedly.

Again, it's very important to test this rule and determine if it breaks any other existing rules. When you're satisfied that it's working and doesn't impact any other processes, you might finally consider an incident rule to prioritize the tickets as they come in. Incident rules apply directly to a specific incident when the criteria are met. In our case, any incident relating to Peoplesoft would have a high priority and urgency no matter what. So, we configure our incident rule, much like our routing rule, with the Title being the criteria. The criticality is pre-determined by the impact to our users based on the application.

Click to view.

Once this process is complete, incidents will be generated by customers through email and prioritized automatically before being assigned to the appropriate queue. This can be built into existing and future SLAs or referenced in support documentation prior to an upgrade release. Overall, it works to alleviate some of the routing help desk staff are typically overwhelmed with and decreases the margin of error. Altiris has provided some great functionality so put it to good use and be creative with it.