A rule is a statement of automated logic that the system executes to perform an action. For example, these are some typical rules:
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.
There are three types of rules available, which are categorized by their triggers.
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:
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:
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 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 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:
By default, only one time-based or aggregate rule is allowed to run in a knowledgebase at any one time. 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, 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.
Use the General tab to configure some basic settings for the rule.
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."
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. 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.
On the Rule Type tab, you select the type of rule you're working with.
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.
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.
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.
Use the Schedule tab to set when the rule is active, how often it runs, and its priority.
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.
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.
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.
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.
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 by selecting the appropriate option in the Background processing type section of the Email Action wizard. This makes sure it's sent before any of the actions that follow.
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: