Macros and SLA
Prepared multi-action responses, and per-priority response and resolution targets.
Macros
A macro is a saved sequence of actions you apply to a ticket in one click: answer, tidy, move on. Manage them under Settings, Macros; apply them from the Macros picker in the ticket composer's toolbar.
Creating a macro
Click New macro. Give it a name and an optional description ("when to use this macro"), then add actions. Five action types exist:
| Action | What it does |
|---|---|
| Reply to customer | Sends the prepared text as a reply. |
| Internal note | Adds the text as a note the customer never sees. |
| Set status | Moves the ticket to open, pending, on hold, solved or closed. |
| Set priority | Sets low, normal, high or urgent. |
| Add tag | Adds a tag. |
A macro can hold several actions and runs them in order. An action that would change nothing (the ticket already holds that status, priority or tag) is skipped rather than recorded twice. The Enabled switch takes a macro out of the picker without deleting it.
Creating and editing macros needs editor or above; deleting one needs admin.
Applying a macro
On a ticket, open Macros in the composer toolbar and pick one. The actions run immediately and the thread refreshes to show what happened, each action as its own event with you as the actor. Applying needs editor or above.
Automatic macros
Macros can also fire on their own: a trigger watches ticket creation or update against conditions (status, priority, source, team, assignee, tag, subject) and applies the macro when they match. Triggers are configured through the API today; there is no screen for them in settings. The selection rules are built so a macro's own changes cannot re-trigger another pass, so a macro cannot loop.
SLA policies
An SLA policy gives tickets of one priority a first-response target and a resolution target. Manage them under Settings, SLA policies.
Creating a policy
Click New policy: name it, pick the priority it applies to, and set the first-response and resolution targets in minutes (either can be left blank). For example: urgent, 60 minutes to first response, 240 to resolution. Each policy has an Enabled switch.
Creating and editing needs editor or above; deleting needs admin.
How tickets are stamped
When a ticket is created (or reopened), the oldest enabled policy matching its priority stamps the deadlines: first response due and resolution due, counted from that moment. Create your policies before the tickets you care about arrive, because the stamp happens at creation.
Two details that matter in practice:
- Deadlines are wall-clock. Moving a ticket to
pendingoron_holddoes not pause the resolution clock. Only reaching a terminal status takes a ticket out of breach's reach. - Your first reply is what stops the first-response clock. Internal notes do not.
Breach behaviour
A scanner checks the live statuses (open, pending, on hold) continuously. When a deadline passes, the ticket is flagged as breached, an SLA-breach event lands on its timeline, and the assignee is notified; if the ticket has a team and no assignee, the whole team is. Breached tickets appear under Overdue in the Inbox sidebar and carry a red Overdue chip. The flag records which target was missed, first response or resolution.
Reopening a solved or closed ticket clears the breach flag and stamps fresh deadlines, so a reopened ticket gets a fair clock rather than arriving pre-breached.