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.

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:

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:

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

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.

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:
  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:
  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:
  3. Select what happens when the records that the rule affects are saved:
  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:
  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:
  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.


    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.

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.

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.

Related articles