Incident vs Validation vs Routing Rules

At our organization we have been using the Altiris Helpdesk Module for nearly two years. In that time we have made customizations to forms, added custom lookups, and generally taken advantage of the flexibility available in the Helpdesk module. All the while we've found the technical documentation to be adequate, but sometimes a quick guide with practical examples on using the various Admin options within the Helpdesk module can be more advantageous.

Of particular interest have always been the differences between three of the five rule types: Validation, Incident, and Routing. I have often found myself explaining the rule types again to both my manager and other members of the Change Advisory Board.

Validation rules:

Validation rules display a message when either entering or modifying an incident. These messages are often designed to prompt a worker to provide more information or make changes to the incident so it falls in line with your incident process.

Example:

One of the first things we noticed was that many of the built in queries were getting inflated numbers. Upon investigation we found that several incidents were being set to a "Closed" status while still assigned to those queues. Our ticket flow here is one where the resolving worker should be assigned that incident when it is closed.

We will want to display a message asking people to make sure they re-assign the ticket to someone before they close the incident. We could use another type of rule to "automatically" assign it to the modifying worker, but if someone is helping modify incidents it is possible it will go to another user.

Here's something of what it should look like when you're finished entering it:

Click to view.

The dropdowns on your conditions have the same Advanced Condition option that many other Altiris options have. Here you can use special functions within the Helpdesk module or even columns from the Workitem table that you don't see in your dropdown box.

One such example would be the validation rule we recently created to prevent the creation of incidents without a contact. However you will notice that there isn't anything readily available to allow you to specify it has to include something. Every effort to constrain the contact information to require even a specific domain did not seem to work for me. So, by doing a little bit of research we found that the [none selected] contact's id was 1. We did this by creating an incident without a contact and then temporarily modifying the tables I view on my worker report to include the contact id column. Then, by creating an advanced condition comparing the column workitem_contact_id to the number 1 we get the condition we need to display the message we have chosen.

Your condition should look a little like this when it's completed:

Click to view.

The final validation rule looks a little like this:

Click to view.

It is important to note that any validation rule you use can cause automatic ticket creation to explicitly fail. Things such as creation by e-mail box, the winuser console, and Automation rules, probably even Workflow solution (though I can not say for sure since I have not used it in production yet.) still follow the rules you have defined within the Altiris Helpdesk Module.

Using the checkbox marked "Log message to Notification Server. . ." will show these messages on your log. This log can be viewed by going to "http://<NSSERVER>/Altiris/ns/logview.aspx".

Incident Rules:

Incident Rules can be viewed in two different ways. An incident rule is essentially a way to automatically modify an incident based off a set of criteria similar to those criteria that might show a "Task" as being available or a message specified within a Validation rule.

Incident Rules vs Validation rules? Well incident rules are much the same, but will force a specific value on an incident instead of prompting for additional information or providing a list of values. Incident rules always apply only to the incident that is currently being evaluated.

My experience has been to use these sparingly. Only when I absolutely know 100% that a particular value must be set under specific conditions have I used this. It works very well for controlling status during ticket flows when you have setup custom reports that depend on those being exact.

Example:

When writing a series of reports to measure Service Level Agreement (SLA) compliance we had to make sure that we were measuring time between "Assigned" and "Closed" statuses. To do this obviously we had to make sure that when an incident was sent to a resolving team the status was set to "Assigned". After specifying what properties were to be modified, in this case status. We just had to specify under what conditions to modify it.

In the end our incident rule looked a little like this:

Click to view.

An important item to note would be Incident rules are evaluated and executed in the order in which they are listed when you view the list of those items. I suggest you take time to carefully consider the order in which these rules need to be evaluated and the need to "terminate" rules evaluation so you don't end up with an incident being modified in an unexpected way.

Routing Rules:

Routing rules are a specific type of Incident rule that is intended to help with the assignment of incidents. As it sounds you select a number of categories and the queue or worker that they get assigned to automatically. The usage of this type of rule is going to depend heavily on your organization's business process. Some organizations may run into issues attempting to define "ownership" of a particular category. Routing rules also allow you to define the default worker or queue an incident is assigned to if no Routing rules are applicable and --[auto]-- is selected.
These also evaluate rules in order and should be checked to make sure you are terminating the rules evaluation in the proper order. I suggest looking into the built in rules for examples of how to proceed with creating your own routing rules.

There are two other rules "types" Notify and Automation. They can be very in depth so I plan on trying to cover those two in a separate article. Just another effort to try to get real world examples out there. I know that seeing those help me I just hope that seeing these examples from our environment will help you too.