A rule is a statement of automated logic that the system executes to perform an action. For example, these are some typical rules:
Rules are used to create a powerful system that can automatically perform multiple actions. With rules, you can automate email notifications, lead users through appropriate workflows and processes, populate field values, assign records to individual users or teams, generate new records or delete existing records, run scheduled imports and exports, and more.
Rules are triggered by different conditions, and these conditions are highly customizable. For example, one rule might email the contract manager whenever someone creates a new contract. In contrast, another rule might delete thousands of old support cases and runs only once every 30 days during non-working hours.
You can choose which records a rule operates on with a saved search. This focuses the rule so it only processes relevant records. For example, instead of running a data validation rule on every record in the table, you might run it only on records where the relevant data was updated.
uses three different types of rules. These rules are categorized by how they are triggered in the system. There are event-specific rules, time-based rules, and summary condition rules.
Event-specific rules are the most common type of rule and run when a record is created or edited. In practice, the "Deleted" option is almost never used. Event-specific rule names should begin with either Create, Edit, or Create/Edit depending on which event causes them to trigger. Some examples of event-specific rules are:
The "Only when the change occurs by means of:" section is used to limit the system interactions that cause the rule to run.
For example, if a rule should send an email to a contract manager whenever the contract is updated by a user, select Edited and Web. If a rule should send an email to an accountant whenever a new Travel Expense record is created by a rule, select Created and API. If a rule should send an email to a developer whenever a new Developer Task record is created or edited by a user or rule, select Created, Edited, Web, and API. This is one of the first areas to consult when troubleshooting an event-specific rule.
Time-based rules are triggered at specified time intervals, such as every four hours, once a day, or every Monday. They're often used for automating escalations and notifications, as well as scheduling resource-intensive actions like imports during non-business hours. Consider these time-based rules:
Time-based rules can be triggered at any time of day, but their maximum frequency depends on how your knowledgebase is hosted. If your knowledgebase is hosted on servers, time-based rules can't run more often than every 5 minutes. If you use your own server to host your knowledgebase, you can shorten the minimum frequency on the Knowledgebases tab of the admin console.
If an error occurs during a time-based rule, an email is automatically sent to members of the admin team and any child teams.
For troubleshooting purposes, it's important to be able to tell if an email is generated by a time-based rule or an email is generated by a scheduled report. For more information on reports, visit the Reporting page or the Schedule section of the Create and Edit Charts and Reports page. |
Summary condition rules are triggered based on the number of records in a table that meet a specified condition at a specified time interval. Consider these summary condition rules:
Summary condition rules are the only rule type that actually requires a saved search during configuration.
By default, only one time-based or summary condition rule is allowed to run in a knowledgebase at any one time. If you host Agiloft on your own server, you can modify this by customizing the Max Timer Rules per KB global variable. |
Rules are created and edited with the Rules wizard. To access the Rules wizard, click Setup [Table] on the left pane and click the Rules tab. In the list of rules, click New to create a new rule, or click the edit icon next to an existing rule. Alternatively, you can access all the rules in your system by clicking the Setup gear in the top-right corner going to Rules.
Use the General tab to configure basic settings for the rule, such as the rule's name and how the rule generates history entries.
Provide a description for the rule. Be as descriptive as possible so that another admin can look at the rule and know its purpose. For more information on naming rules, see Organizing and Naming Rules.
Select whether the rule is enabled.
If you're configuring rules in a system that is not yet live, it's often a good idea to disable time-based rules until the system goes live. |
Do not record history entries: The rule never generates history entries, even if it modifies records.
Test the potential impact of the rule and come back to this section later to properly determine how the rule should produce history entries. If you are using a time-based rule that runs on frequent intervals or as a series of nested rules, consider using the "Only record history entries when record is modified by actions called by the rule" option. This way, the History tab stays clean and decluttered. Huge history tables can increase backup time, complicate troubleshooting, and cause other performance issues. |
Select the rule type here. The remaining tabs of the Rules wizard differ based on the selection made here.
Select the type of rule:
Run in background: Forces the rule to run after all other triggered rules have completed their changes. If a rule depends on changes made by other rules, use this option. If a system is running slowly, check your rules and make sure Run in background is selected for rules that impact a lot of records.
Use the Condition tab to determine when the rule runs. The first section of the Condition tab changes depending on the decision in the Rule Type tab. The "When saving a record" and "Condition" areas of the Condition tab are always present, regardless of rule type. However, for event-specific rules, the tab is referred to as Search Condition.
By default, you're notified before running a rule that matches more than 100,000 records. If you choose to run such a rule, it only affects the first 100,000 matching records. You can change this behavior at the admin console or KB level by setting new values for the following global variables: |
This concludes the Condition tab section for event-specific rules. Feel free to skip ahead to the Schedule tab if you do not require information on time-based or summary condition rules.
This concludes the Condition tab section for event-specific rules. Feel free to skip ahead to the Schedule tab if you do not require information on summary condition rules.
Use the Schedule tab to set when the rule is active and its order of priority relative to other rules in the table. All rule types include both the Rule is Active and Priority sections. Time-based and summary condition rules have extra sections called Apply the Rule and Start Time, which are used to determine time intervals. Summary condition rules have a unique section called Frequency.
Select whether the rule is always active, active only during the working hours of a desired team, or active only outside the working hours of a desired team. Certain rules, such as rules that run scheduled imports, are typically set to run outside of a team's working hours because they can have a negative impact on system performance.
After you finishing configuring the rule in the Rules wizard, it's a good idea to double-check that the team you've chosen has the working hours you expected. |
Set the rule's priority. Rules execute in their priority order relative to other rules in the same table, and rules with the lowest number execute first.
Rules that rely on information updated by other rules must run after those rules; a lower priority correlates to a higher value. For instance, if rule A relies on information updated by rule B, you must give rule A a higher value so that it runs after rule B. |
For summary condition rules, select how frequently the rule should run with the Frequency section.
Once: Applies the rule when the condition is met, then does not apply the rule again until the condition is broken and then met a second time. For example, consider a rule that sends a message if the number of open issues exceeds 10. If the frequency is once, the rule sends a message when the number of records reaches 11, but doesn't send any more until the number drops below 11 and then rises again.
For as long as the condition remains true: Runs the rule every time the saved search returns a record. If you select "for as long as the condition remains true" for the same rule, the rule sends a message for every record the saved search finds that exceeds 10. You receive a message for record 11, 12, 13, and so on.
Use the Action tab to add actions to the rule. Actions are executed in the order listed from top to bottom, but subsequent actions don't use values updated by previous actions. This means that if subsequent actions rely on values updated by previous actions, you must place the subsequent actions in a separate rule that runs after the initial rule is complete. This is necessary because values aren’t saved to the database until the rule is completely finished running.
For example, suppose you have a rule that runs an Update Fields action to change the status of a record from Closed to Reopened if the Additional Information field is updated. Let's say you also want to run a Validate action that notifies the user that they can call a support line if the priority is Critical when the status changes to Reopened. If you don’t place these actions in separate rules, the system won't recognize the change to Reopened, and the Validate action won't run, even if the record's priority is Critical.
It's a good idea to put all Validate actions in a rule that runs before any others. This prevents other actions from making changes before any validations can run. |
Determine the order of the selection actions by selecting the action and clicking either Move Up or Move Down.
Click Finish to create the rule.
Email actions run in the background by default. This means that they might not complete before the next action. For example, if you have an Email action followed by an Update Fields action, the fields might be updated before the email sends, making the email unexpectedly include the updated field values. You can choose to run an Email action in the foreground in the "Background processing type" section of the Email Action wizard. This makes sure it's sent before any of the actions that follow. |
When you save a record and trigger rules, various system actions occur in a regimented order. For example, rules that are executed in correlation to their priority order is one such system action. It's important to know when a rule runs, relative to other system actions. This allows you to better anticipate how the system behaves when a user saves a record.
When a record is saved, system actions are executed in this order:
Interactions between rules, priority order, and order of execution are important variables to consider when you design rules. Rules can overlap, invalidate one another, trigger other rules, run on incorrect values, and cause other problems if you don't consider these factors during the design process. To solve existing issues with rules, consider checking out Troubleshooting Rules. |
Usually, it's better to disable a rule instead of deleting it, in case you need the rule in the future. If you're configuring rules in a system that is not yet live, it's also a good idea to disable time-based rules until the system goes live.
To disable a rule:
Related articles |