Automation rules & SLA policies

Events, conditions and actions; how rules order and chain; and the one thing almost everyone gets wrong about SLA clocks.

Automation rules and SLA policies are separate systems that meet in one place: an SLA state change is an event that automation rules can react to. This page covers both, plus round-robin assignment — which people reasonably but wrongly expect to be an automation action.

The anatomy of a rule

A rule is an event, a list of conditions, and a list of actions. When the event fires, every condition is checked against the live ticket; if they all pass, the actions run in order. Conditions combine with AND — there is no OR, so "urgent, or from a Pro customer" is two rules.

Events

Eight events can start a rule: ticket.created, ticket.assigned, ticket.status.changed, ticket.priority.changed, ticket.reply.customer, ticket.reply.agent, sla.at-risk and sla.breached.

Conditions

A condition is a field, an operator and a value. The available fields are status, priority, channel, subject, tags, assignee, team, SLA first-response state, SLA resolution state, and two contact fields — customer plan and customer email. The contact record is loaded only when a rule actually references it, so referencing customer fields costs nothing on rules that do not.

Operators are is, is not, is one of, is none of, contains (case-insensitive, for text such as the subject), has (for the tags list), and greater-than / less-than for numeric comparisons. The editor offers only the operators that make sense for the field you picked, which prevents most broken rules being written in the first place.

Actions

There are nine action kinds:

• Set status, Set priority, Set assignee, Set team
• Add tag, Remove tag
• Post internal note — a system note on the thread, visible to agents only
• Notify assignee — with your own message text
• Apply macro — runs a saved macro's steps against the ticket

Note what is absent: there is no "send an email to the customer" action. Automations change the ticket and tell your team; replying to a customer stays a deliberate human act.

Ordering, chaining and failure

Rules bound to the same event fire in their configured order, then by creation time. Actions within a rule run top to bottom. If an action fails, the failure is logged and the remaining actions and rules still run — one broken rule does not stop your whole automation stack.

An action that mutates a ticket can emit a further event, so a rule that sets a status can trigger a status-changed rule. That is useful and occasionally dangerous, so chains are capped at eight levels deep; beyond that the cascade is abandoned and logged. If a rule stops behaving, look for a loop before anything else.

Every rule has an on/off toggle, so you can pause one without losing its configuration, and each tracks how many times it has run and when it last fired. There is no dry-run or rule-testing mode, so the practical way to introduce a risky rule is to give it narrow conditions and a harmless action — add a tag, post an internal note — watch the run count for a day, then swap in the real action.

The Free plan allows three active automation rules; paid plans are unlimited.

Round-robin assignment

Round-robin is not an automation action and cannot be attached to conditions. It runs at ticket creation, and it picks from agents who are marked available and are currently online. If the ticket belongs to a team, the pool is scoped to that team's members, and each team rotates through its own counter so one busy team does not skew another's rotation.

If nobody in the pool is online, Leodesk falls back to agents who are available but offline — routing to someone beats leaving a ticket in limbo because a browser tab was closed. If there is no eligible agent at all, the ticket stays unassigned in the queue for someone to pick up. Online status is real presence, derived from an open app session or recent activity, not a manual toggle an agent forgets to flip.

A mailbox with a default assignee bypasses this entirely, so leave that field empty on any channel you want routed rather than pinned.

SLA policies

An SLA policy sets a first-response target and a resolution target, in minutes, per priority. When a ticket is created, the applicable policy stamps two deadlines onto it. Each target then moves through four states: on-track, at-risk, breached and met.

A worker scans open and pending tickets roughly once a minute. A ticket flips to at-risk when its elapsed time crosses a percentage of the total budget — 80% by default, configurable on the policy — and to breached once the deadline passes. Each transition also emits sla.at-risk or sla.breached, which is how you build escalations. A rule on sla.breached that raises priority, reassigns to a lead and posts an internal note is about the most valuable automation most teams ever write.

First-response state is locked the moment an agent posts their first reply: met if it landed before the deadline, breached if after. Later replies do not change it. Resolution works the same way when the ticket is resolved or closed. Once locked, a state stays locked — the number you report on is the one that was true at the time.

SLA deadlines are wall-clock

This is the single most important thing to understand, and it is the assumption most people bring from other tools that is wrong here. A deadline is the ticket's creation time plus the target in minutes. Nothing else enters the calculation.

The clock does not pause outside business hours. It does not pause at weekends, and it does not pause on public holidays. A ticket that arrives at 18:00 on a Friday with a four-hour first-response target is breached by 22:00 that Friday, whether or not anyone was supposed to be working.

Business hours do exist as a workspace setting, but they drive the chat widget's availability display and its offline message — they are not wired into the SLA clock. So set targets that reflect real elapsed time. If you cover business hours only, an overnight first-response target needs to be long enough to survive the night, or your breach numbers will end up measuring your opening hours rather than your responsiveness.

Where to start

Two rules and one policy cover most teams. Write a rule on ticket.created that tags and routes by channel or subject keyword, and a rule on sla.breached that escalates. Set one SLA policy with generous targets, watch a fortnight of real data, then tighten. Targets you actually hit are worth more than aspirational ones you breach every night.

If you want events mirrored into your own systems as well, the outbound webhook surface fires on ticket creation, status changes, replies, notes and macro applications.