Rule evaluations
A rule is evaluated when there is a change to an instance of an object, which is of the type specified in the rule’s object type. When a rule is evaluated, its conditions are checked, and if satisfied, the rule is started.
Rules are reevaluated and can be invoked again when a rule creates a new object or changes the state of an object.
Evaluations and reevaluations have the following behavior.
- Multiple automatic rules. If a change to an instance of an object starts multiple automatic rules, all the rules must run before the rules can be reevaluated. In a scenario where an automatic rule modifies an object, a follow-on rule does not see that modification until all the rules are completed then reevaluated. However, if an automatic rule runs a workflow that modifies the object, a follow-on rule (after the workflow completes) can act upon that change.
- Infinite loops. To guard against infinite loops, the Orchestration & Automation application limits the rule creation of new objects to 500 while processing rules. If you see a message that states the number of rule evaluations in a single session were exceeded, make sure that the rule did not inadvertently create an infinite loop.
- Auto-activated task. When an automatic rule creates a task, that task is an "auto-activated"
task. It means that if the rule is reevaluated and the rule condition is false, then its tasks are
deactivated and hidden. This behavior is useful in many situations. For example, an automatic rule
creates tasks in response to a malware event, which is later determined to not be malware; those
tasks are then deactivated.
This behavior can be confusing to a user when the conditions reference a state, such as ‘the incident is created.’ For example, an incident creation event starts an automatic rule that creates one or more tasks. If a user modifies the incident, the rule is reevaluated and as the incident was already created, the rule evaluates to false. Therefore, any tasks that are created by the rule are deactivated.