Automation rules
Rules are an event, some conditions and some actions. No scripting language, and nothing fires without being written down.
The shape of a rule
Pick an event (a ticket was created, an SLA warned, a ticket was resolved), add conditions that must all be true, and list the actions. Conditions and actions are written as short JSON.
Actions available
- Notify the workspace admins, or a named person
- Add an internal note
- Escalate, or set a status
- Send an email
- Write a line to the run log
- Outbound webhooks are set up separately (Settings → API & Webhooks) and fire on the same events
Bounds you cannot turn off
Twenty actions per firing, a recursion depth of three and a per-rule hourly rate limit (60 by default). These exist because a rule that sets a status which triggers the same rule is the classic way to send four thousand emails in a minute.
Where rules go wrong
Almost every rule that causes trouble does one of three things: it notifies on an event that fires far more often than the author expected, it sets a field that another rule watches, or it has a condition that is true for every ticket because a filter was left empty. Read the conditions back as a sentence before you save.
The run log
Every firing is recorded with the record it fired on, the conditions that matched and each action's result. When somebody asks why a ticket was reassigned at two in the morning, this is the answer, and it is the first place to look when a rule appears not to be running at all.
Try a new rule safely
Start a new rule with a single log or add-note action and watch the run log for a day. When it fires on exactly the records you expected, add the real actions.