When a rule runs against an entity, it can reach different "stages." Several settings in the rule configuration ask you to choose one of these stages as a condition — for example, when deciding when a particular action should happen. This article explains what each stage means.

The three events

Execution The rule ran and evaluated the entity. This happens every time the rule is checked — no matter what the outcome is.

Trigger The rule's condition was met. This is a subset of Execution: the rule still had to run first, but this event only counts if the logic evaluated to true.

Ping A case (ping) was actually created as a result of the rule triggering. This is the narrowest event — it requires the rule to have triggered and for that trigger to have resulted in a ping being raised. Some rules can trigger without creating a ping, in which case this event would not count.

How they relate

Think of these as three nested levels, from broadest to narrowest:

Execution → Trigger → Ping

• Every Ping requires a Trigger.
• Every Trigger requires an Execution.
• Not every Execution results in a Trigger.
• Not every Trigger results in a Ping.

Example

Say a rule checks whether a transaction exceeds a certain amount:

1. The rule runs on every incoming transaction → this is an Execution.
2. If the amount exceeds the threshold, the rule's condition is met → this is a Trigger.
3. If that trigger leads to a case being opened for review → this is a Ping.

If the transaction is under the threshold, the rule still executed, but did not trigger, and no ping was created.