A rule is a statement of automated business logic that

For example: "Email the sales manager whenever a new lead arrives" or "Do not allow a bug report to be deleted unless it has been closed"

There are three kinds of rules available:

Event-specific Rules

...

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 

...

...

.

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".In all cases additional conditions may be applied using a saved search. The Schedule tab allows you to control when the rule is active, for instance to limit it to the working hours for a particular team..
• 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.

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

   Tip
   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.
     Image Added

     Tip

     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.
   Image Added
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.

     Note
     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,

Creating, editing, and deleting rules

To create, edit, or delete rules, go to Setup > Rules.

It is not necessary to delete a Rule if you think you might need it in future.

To deactivate a rule:

1. Navigate to Setup > Rules.
2. Select the rule in question and open it for editing.
3. Click Action.
4. Select all actions in Active Actions window.
5. Move them to Inactive Actions.

Rule Configuration

Rules can be named to make them easier to group in the Rule wizard. For instance, it is useful to group the time-based rules by using the syntax Ticket TB - Name of rule for a time-based rule on the Ticket table.

Rules can easily get out of hand and grow in number, and if they are all done separately, it can be hard to control their order of execution. The best practice is to group automation into a smaller number of rules. In general, any table with lots of automation will typically have the following "parent" rules:

...

Rule 1:

...

all new record actions 
all new validations in an if-then action 
all new conditional actions in an if-then action 
any other separate actions on new records

...

Rule 2:

...

All edit validations. Usually customers who start setting up validation criteria end up having several of them and so we group them all into one rule. If there is only a single edit validation, then it can go in one of the other rules below.

...

Rule 3:

...

Edit actions when power users update.

...

Rule 4:

...

Edit actions when end user updates.

...

Rule 5:

...

Parent-child handling. If complex, this may need its own separate rule with all actions in an if-then; if not, it might go into one of the above rules.

...

Rule 6 - infinity:

...

Rules that must be defined separately from other ones in order to be triggered by changes made by the others, or rules that should not include API when the rule they might otherwise go in includes it, or which must include API when a possible containing rule omits it.

For instance, a rule based on customer updates should never include API changes because since other rules run currently in name of last updater, if any other rule fires, the system will think the customer has updated again and will re-trigger that rule. That is why it us usually suggested to separate customer update rule actions from staff edit actions. There may be some staff edit actions that must be separate too because of a need to include or exclude API triggers.

...

Rule 7 - infinity:

...

Time based rules - It is usually preferable to combine them whenever possible into if-then conditions, but sometimes it is cleaner to make a separate rule for each one, unless there are 10s or hundreds of them, as long as they are named so you can sort them and see them all together, i.e. named for "table name TB - description".

The basic goal is to have as few rules as possible per table. Otherwise, a complex system will have hundreds of rules which can make sorting laborious, and they become much more difficult to troubleshoot, prioritize, and document.

Priority Order

...

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

   Tip

A given rule can execute multiple actions and these actions execute in the order that they are listed.

Where possible, try to combine rules for a given table into a few, or even a single if-then-else rule. A few if-then-else rules are both more efficient and easier to manage than a swarm of independent rules.

Order of Execution in Saving

Many checks are run on a record when it is saved. There may be field validation, rules, workflow actions and guards, and custom scripts run as a result of saving. It is important to understand the order that these actions execute. In order, they are:

1. Form validation is run on any validated fields.
2. Dynamic default values are updated, the Updated By and Date Updated fields are populated.
3. Rules based on record modification are executed in priority order.
4. Workflow guards are executed. If they fail, the record is returned to its former pre-saved condition.
5. Workflow actions are executed.
6. Any scripts associated with rule or workflow actions are executed with the associated rule or workflow, and if their validation fails, the record is returned to its pre-saved condition.

Please note that, by default, you will see a warning before running a rule that matches more than 100,000 records. If you choose to run such a rule, it will only affect the first 100,000 matching records. You can change this behavior at both the Admin or KB level by setting new values for the following global variables:

• Max Rule Records Limit
• Max Rule Records Warning

Rules that Trigger other Rules

Changes made by one Rule can trigger the execution of other rules.

Edits made by a Rule are defined as API actions, and do not change the Updated By field.

...

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.

   
   

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

   
   

   Info
   title Example

...

In a normal business process, 

To prevent the tech being overwhelmed with autogenerated emails, the admin edits the Rule, unchecking API so that an email notification is not sent after a rule-triggered (API) change.

Alternately, the admin may create a single, more complicated if-then-else rule to replace the several simpler rules.

1. 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.
   Image Added
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

Applying Rules

The Condition tab of the Rules wizard contains the options to define when the rule should be applied. For example, if you select Edited and Web, the rule will only be applied if an Approval was edited using the Web interface.

The possible triggers for a rule include: 

• Email -  all updates from inbound email.
• Web - user interactions with records through the web portal; REST and Web Service calls, because the Web Service call creates a user session and performs edits on behalf of a named user.  
• API triggers include: 
  • Record edits by a rule or workflow action
  • Automatic calculation field updates
  • Synchronization actions, including automatically triggered updates such as creation of Twitter responses
  • Record creation in cases where the user does not interact with the record form, for example during data imports from files and silent conversion actions. 

API triggers

The...

Note: Since executing rules is counted as an API trigger, deselecting the API checkbox will prevent the changes made by other rules from triggering this rule. This is particularly useful for rules based on updates by specific individuals, for instance rules based on the customer updating the record. When rules cause field changes to a record they are stored as modifications by the individual who last updated the record. If you have a rule that is meant to be triggered when the customer updates the record, you will want to disable it from running on API updates so that the rule is not falsely triggered by the execution of other rules updating the record in the name of that user.

Rules based on the Activity Logs table

...

1. .

...