A rule is a statement of automated logic that the system executes to perform an action. For example, these are some typical rules:

• When a new Lead record is created, email the sales manager.
• When someone tries to delete a Bug Report, check that the status is closed. If the status is anything except closed, prevent the user from deleting it.
• When a Contract is created, automatically set the renewal date to one year from now.
• When a user selects a workflow in a Service Request, automatically create Task records linked to that workflow.

Rules have many uses, and using them allows you to create a powerful system that can automatically perform many operations. For instance, 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 always be active and run whenever a Contract record is created. This might be the case if you want to email the contract manager whenever someone creates a new contract. Another rule might only be active during non-working hours and run every 30 days. You might want a rule like this if you need to delete thousands of old Support Case records but don't want your system to slow down when people are working.

You can also choose which records a rule operates on by using a saved search. This allows you to increase how quickly a rule processes records by configuring it to only operate on records that are relevant. For example, imagine you have a rule that runs when a Contract record is created or edited. The rule contains an If-Then-Else action that checks if the contract start date is before the end date. If it isn't, the rule runs a Validate action that prevents the user from saving the record. In a case like this, you could create a saved search so that the rule only runs on records where the Contract Start Date or Contract End Date fields have changed.

Rule Types

There are three types of rules available, which are categorized by their triggers.

Event-specific Rules

Event-specific rules are the most common type of rule and are triggered when a record is created, edited, or deleted. Here are some examples of event-specific rules:

• Email the contract manager when a new contract record is created.
• When a customer creates a support record, automatically assign it to the Support team.
• If a user tries to delete a contract that isn't complete, warn them before it can be deleted.

Time-based Rules

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 during non-business hours, such as scheduled imports or exports. For example, consider these time-based rules:

• Every night at 10 PM, import data into the Leads table to create new records.
• Notify the support manager once a day of all open cases that have critical severity and were created more than 1 day ago.
• Notify the assigned person that the due date for a task is today.

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  Agiloft servers, time-based rules are limited to running every 5 minutes. If you use your own server to host your knowledgebase, you can shorten the frequency on the Knowledgebases tab of the admin console.

Aggregate Rules

Aggregate rules are triggered based on the number of records in a table that meet a specified condition at a specified time interval, also called summary conditions. For example, these are some aggregate rules:

• Notify the Sales Manager if the number of Leads expected to close next month is less than 20 or more than 40.
• Email the contract manager every Monday if the contracts expiring this month are valued at more than $100,000.

Creating and Editing Rules

Rules are created and edited with the Rules wizard. To access the Rules wizard, go to Setup > Rules, or click Setup [Table Name] 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.

General Tab

Use the General tab to configure some basic settings for the rule.

1. Provide a description for the rule. Be as descriptive as possible so that another admin can look at the rule and know its purpose.

   Add a prefix to the description that indicates how the rule is triggered. For example, if the rule is triggered when a record is edited, you might have a description like "Edit: Generate Tasks when triggered from Change Requests." For a time-based rule, a description might say "TB: Notify about expiring insurance certificates."

2. If you're creating a new rule, select the table in which the rule will run. If you accessed the Rules wizard from the Table wizard, the current table is automatically selected.
3. Select whether the rule is applied to any subtables. This refers to any existing subtables and any subtables that are added after the rule is created.

4. 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.

5. Select how you want the rule to generate history entries:
   
   • Always record history entries: The rule generates history entries whenever it runs.
   • Only record history entries...: The rule only generates history entries when it modifies records with the actions it contains.

   • 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. Restricting when history entries are recorded can be useful, especially for time-based rules that run at frequent intervals or as a series of nested rules. These types of rules can quickly clutter up the history with thousands of entries. Huge history tables can increase backup time and cause other performance issues, so you may want to use one of the other options to reduce history size.

6. If you're working with a time-based or aggregate rule, you can click Save & Run Now to test the rule without waiting for the scheduled run time.
   
7. Click Next.

Rule Type Tab

On the Rule Type tab, you select the type of rule you're working with.

1. Select the type of rule to create:
   • When a [record type] is created/edited/deleted: Creates an event-specific rule. If you select this type of rule, you have two additional options:

     • 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. For example, if one rule uses a record's status to assign the record and a different rule sets the record's status, you can force the rule that assigns the record to run in the background. This ensures the rule that sets the record's status runs before the rule that assigns the record.

     • Disable loop protection: Turns off the loop protection mechanism, which means that rules that precede or triggered the current rule can be retriggered by the current rule. This creates the potential for infinite loops, so this option is not generally used.
   • At selected time-intervals: Creates a time-based rule.
   • When some summary condition...: Creates an aggregate rule.
2. Click Next.

Condition Tab

Use the condition tab to define the conditions under which the rule runs. The available options depend on the type of rule you're working with.

Event-specific Rules

1. Select whether the rule is triggered when a record is created, edited, or deleted. You can select multiple options.
2. Select how the change must occur for the rule to be triggered:
   • Email: An change is made with inbound email.
   • Web: A user interacts with a record on the interface, or a REST or Web Service call makes a change.

   • API: A rule or action makes a change.

     When a rule updates a field in a record, the update is stored as a modification by the user who last updated the record. This means that if you have a rule that you only want triggered when a customer updates the record, you must disable it from running on API updates so that it's not falsely triggered by other rules that might update the record in the name of the customer.

3. Select what happens when the records that the rule affects are saved:
   • Run rules: Allows other rules to be triggered by the changes.
   • Update defaults: Updates default values in the records, such as the Date Modified and Last Updated By fields.
4. If desired, select or create a saved search that the records must meet for the rule to be triggered. For example, if you have a rule that assigns certain change requests to the change manager, you might use a saved search to specify that the Urgency field be set to Emergency for the rule to be triggered.
5. Click Next.

Time-based Rules

1. Select if the rule runs according to the interval selected on the Schedule tab or when it finds records that meet the saved search condition.
2. Select what happens when the records that the rule affects are saved:
   • Run rules: Allows other rules to be triggered by the changes.
   • Update defaults: Updates default values in the records, such as the Date Modified and Last Updated By fields.
3. If desired, select or create a saved search that the records must meet for the rule to be triggered.
4. Click Next.

Aggregate Rules

1. Select if the rule runs once if the search is met or once for each record found by the search.
2. Select what happens when the records that the rule affects are saved:
   • Run rules: Allows other rules to be triggered by the changes.
   • Update defaults: Updates default values in the records, such as the Date Modified and Last Updated By fields.
3. Select or create a saved search that the records must meet for the rule to be triggered.
4. Select how many records the saved search condition must find for the rule to be triggered.
5. Click Next.

Schedule Tab

Use the Schedule tab to set when the rule is active, how often it runs, and its priority.

1. Select whether the rule is always active, active only during the working hours of a desired team, or actively only outside the working hours of a desired team.
2. For time-based and aggregate rules, select the start time and how often to apply the rule.

3. Set the rule's priority. Rules execute in their priority order relative to other rules, and rules with the lowest number execute first. For example, a rule with a priority of 1 executes before a rule with a priority of 2. Zero is the first priority and executes before 1.

   Rules that rely on information updated by other rules must be placed in a lower priority. For instance, if rule A relies on information updated by rule B, you must give rule A a lower priority so that it runs after rule B.

4. Click Next.

Action Tab

Use the Action tab to add the actions that the rule runs. It's best to organize your actions into a few standard rules that contain If-Then-Else actions with multiple conditions and actions. Placing your actions into fewer rules helps control their order of execution and makes rules easier to maintain and understand. You should also put all Validate actions in a separate, highest-priority rule. This prevents other actions from making changes before any validations can run.

1. Click one of the buttons to create a new action, or select an action from the Available Actions pane and move it to the Selected Actions pane. Actions are executed in the order listed from top to bottom, but subsequent actions will not 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.

   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.

2. Click Finish to create the rule.

Disabling Rules

In most cases, it's better to disable a rule instead of deleting it. This is because you might need the rule in the future, even if you don't currently want it enabled.

To disable a rule:

1. Go to Setup > Rules, or click Setup [Table Name] on the left pane and click the Rules tab.
2. Click the edit icon next to the desired rule.
3. On the General tab of the Rules wizard, add "Disabled:" to the beginning of the rule description so that it's clear the rule is disabled.
4. Scroll down and select No for Rule is enabled.
   
5. Click Finish. The rule will no longer run, but it's retained in the system if you need to enable it again in the future.