The following guide is designed to give administrators an overview following Rules Engine topics:
- Accessing the Rules Engine
- The different types of rule triggers
- Creating a new rule
- How to edit, copy, delete, or enable/disable existing rules
- Using Rule Simulator
You can use the following links below to quickly navigate to a specific section in this document. To quickly return to this index simply use the Return to Index link located at the end of any section.
- Introduction to Rules
- Creating a New Rule
- Copying, Editing, & Deleting/Disabling Rules
- Using the Rules Simulator
Introduction to Rules
Rules Engine is Incident IQ's powerful tool that helps automate workflows. Rules can be set up to assign tickets to certain teams or individuals based on location, ticket subject, and many other conditions. To access this feature, select Administration > Rules from the left navigation bar.
When a ticket meets a certain trigger condition, Incident IQ will sequentially compare the ticket against the list of currently enabled rules for that trigger type from top to bottom. Please note, Rules Engine does support cascading logic to ensure that information applied by rules earlier in the list is taken into account by rules further down the list.
When a match is found, the rules action's will be applied to the ticket. For ease of tracking, a timestamp with the date and rule that fired will always appear in the ticket's detailed timeline.
Creating a New Rule
When creating a new rule you will first need to select how the rule will trigger on a ticket. You can do so by selecting from the list of triggers provided on the left side of the Rules page.
Once you've selected the type of trigger for your rule simply click on Create New Rule.
In the Rule Properties window, you'll need to name the rule and choose whether this rule is enabled or disabled. You can also assign an expiration date for this rule if so desired. Expiration dates can be helpful if you need to reroute tickets for a certain period of time, such as when someone is on extended leave.
The next section will ask you to assign at least one condition to the rule. Conditions are the variables that must be met for a rule to be fired. Simply put, if a rule is an if-then statement, then a condition is the "if" portion of that statement. To add a condition, click on the Add Filter icon.
This will open up the filter selection window. From here, you can use the left and right columns to quickly select what filter you'd like to apply to this rule.
Once you have assigned a condition to the rule, you will then need to assign at least one corresponding action. Actions are the operations Incident IQ will perform in direct response to a condition being triggered. These are basically the "then" portion of the rule if-then statement.
Finally, you'll need to choose what happens after the rule is fired. By default, rules are set to continue to the next rule in the rules list. Alternatively, you can make this rule an ending point for any ticket that matches the rule's criteria by selecting do not process any more rules.
You can use the Options button in the top right corner of any rule to quickly edit, copy, delete, enable/disable, and move rules to the top or bottom of the rules list.
Using the Rule Simulator
Rule Simulator provides administrators with a tool to comprehensively breakdown what rules did and did not fire on any particular rule. To use this feature being by clicking on the Rule Simulator button near the top-right of the Rules page.
You will first need to select a trigger type as well as the number of an existing ticket to test.
Optionally, you can select a single rule to test against your selected ticket instead of the full list of your district's rules.
Rule Simulator will then sequentially compare the ticket in question against the list of currently enabled rules for that trigger type from top to bottom. If a ticket matches the conditions in any rule it will log the match.
Additionally, when a rule is set up to stop the ticket from further processing, you will see this reflected in the log as well.