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, an asset was returned), add conditions that must all be true, and list the actions. Build it in the form; the JSON view is there if you prefer it.
Actions available
- Notify admins, a role, or the requester
- Add an internal note or a tag
- Escalate, set a priority, set a status, assign to somebody
- Send an email from a template
- Call an outbound webhook
Bounds you cannot turn off
Twenty actions per firing, a recursion depth of three, a per-rule rate limit and a per-tenant daily cap. 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, kept for ninety days. 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.
Test before you enable
Every rule can be test-fired against a real record. It shows what it would do without doing it. Use it — the run log is honest, but it is better to be honest in advance.