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. 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.