Automation

Automation rules handle repetitive work without manual clicks: they route new tickets to a team, raise priority or move the team when an SLA is at risk, notify the assignee and team leads, send webhooks to other systems, and close tickets that have been resolved for a while. Rules are managed in Administration → Automation by users with the Manage automation rules permission (by default: Workspace admin and Service desk admin). Auditors can view rules and their log but cannot change them.

Rule structure

Every rule has a trigger, conditions, and actions. The preview under the form spells it out as one sentence, for example "When status changes to Pending on tickets with subject containing “printer”, then move to team Infrastructure; notify the team leads."

"Approaching deadline" is counted in the business hours of the ticket's SLA calendar, just like the deadline itself. Time outside working hours and paused time are not counted. The threshold is set per policy in SLA policies and is the same one used by the "SLA at risk" queue filter, the dashboard, and at-risk emails.

Conditions are the same for every trigger: ticket type, channel, priority, site, affected service, and subject keywords. They are evaluated against the ticket when the rule runs. The priority checked is the current priority, not the one at creation.

For the Ticket status changes trigger with Pending as the only target status, there is an extra Pending reason condition (waiting for user, vendor, or internal). With it, a rule "waiting for vendor → move to Infrastructure" does not also move tickets waiting for the requester's answer.

Actions

A rule can hold several actions, at most one of each type. Actions always run in order: priority, team, close, then notification and webhook. That way, notifications and webhooks describe the state after the changes.

Changes made by rules appear in the ticket timeline with the actor System and the note "automatically by rule “…”", and in the audit log.

Priority and SLA

Changing priority, by a rule or manually, recalculates SLA targets from the policy the ticket already uses. Two guarantees apply:

• The timer is not reset. Business time already used and the start time stay. Only the target and its deadline change.
• Breaches do not disappear. A target whose deadline has already passed is marked breached before the target changes. If raising the priority makes the new, stricter target immediately overdue, that target is marked breached right away too, and stays breached even if the priority is lowered again. The SLA card keeps saying "Missed … still counted as breached", and reports keep counting it as breached, even if the new target is looser.
• A priority without a target suspends, it does not end. If a rule or an agent changes to a priority without a target and later back to one with a target, the target is reactivated with the same time used (see SLA and due times).

Auto-close

Auto-close is off by default. The Example: auto-close after 7 days button fills the form with the rule "incident Resolved 7 days without a public reply → close", inactive. The rule is saved only when you press Save.

• Counting: N calendar days, including weekends and holidays, since the ticket was last resolved.
• Cancellation: any public reply after resolution, from the requester, an agent, or an integration, cancels auto-close for that resolution. The ticket becomes eligible again only after it is handled and resolved again. Internal notes do not cancel.
• Preview: the form shows how many incidents already qualify right now. Those tickets are closed as soon as the rule is active, at most 100 per minute.
• Confirmation: enabling an auto-close rule, from the form or from the Active switch in the list, always shows that number and asks for confirmation.
• Requester notice: the requester receives the status update like a manual close. Their portal says "closed automatically after N days without a reply since the solution was given".

Only incidents have a Resolved stage. Service requests already end at Completed, Rejected, or Cancelled.

Rule webhooks vs regular subscriptions

Webhook subscriptions in Administration → Integrations receive every event of the subscribed types. The Send webhook action on a rule is different:

Delivery uses the same Integrations mechanism: HMAC signature, six attempts, auto-disable, history, and resend.

Avoiding double deliveries. If the chosen subscription also subscribes to the trigger's event type (e.g. a "status changes" rule sending to a subscription that also receives ticket.status_changed.v1), one occurrence produces two deliveries. The rule form warns about this. Both carry the same original event_id: data.automation.source_event_id equals the regular delivery's event_id, so the receiver can drop one. The simplest option is a subscription without events, used only for rules. Each subscription card in Integrations names the rules that send to it.

Service desk admins can choose subscriptions created by a Workspace admin but cannot see their URL or secret. Creating and editing subscriptions still requires the Integrations permission. Subscriptions and teams still used by a rule cannot be deleted until the rule is changed.

Order and multiple rules

Rules are checked from top to bottom:

• New tickets: the first matching rule sets the team. Tickets that already have a team from the catalog or a mailbox are left unchanged.
• Other triggers: every matching rule runs. When two rules change the same thing (team, priority or status) for the same event, the higher rule wins. The same kind of action in the lower rule is logged as "already changed by rule “…” for the same event". Its other actions, such as notifications, still run.

The 100 rules limit per workspace applies to all triggers together. The rule list can be searched by name and filtered by trigger. While filtered, the order cannot be changed, because order applies to the whole list.

Safeguards

• No duplicates. A rule runs at most once per event per ticket, even if the worker retries or two workers run at the same time.
• Re-checked. Status, SLA, and N-day rules are evaluated by the worker a few seconds after the event. Just before acting, the ticket's state is read again. If the status has changed again, the SLA target is already completed, or the ticket was replied to, the rule is skipped and the reason logged.
• No loops. A rule's action (e.g. close or handoff) may trigger other rules once more, but never the same rule. One rule succeeds at most 10 times per ticket per 24 hours. Events older than 24 hours when evaluated (e.g. after an outage) are skipped.

Execution log

The Execution log tab records:

• New tickets: one row per ticket created while a new-ticket rule is active.
• Other triggers: one row every time a rule matches its event, with the trigger (e.g. "Status changes from In progress to Pending") and every action with its result ("Change team · done — Service Desk → Infrastructure").
• Skipped: the reason is recorded too, e.g. "status was already In progress before the rule ran", "there is a public reply after resolution", or "no recipients".

Filter by result, rule, or trigger, and search a ticket number to answer "why did (or didn't) this ticket change?".

The intermediate steps of "Start work" (New → Triaged → Assigned → In progress) are status changes too. They happen in an instant, so rules waiting for "to Triaged" are usually logged as skipped.