Macros, triggers and canned responses

A macro is a named list of actions that Auralis applies to a ticket in one step. Macros save the repetitive part of support work — the same reply, the same status move, the same routing decision, forty times a day — and they can either be applied by hand or fired automatically when a ticket is created or updated.

What a macro can do

A macro is built from actions, and there are seven kinds:

• Reply — send a message to the customer. This genuinely leaves the building: the reply is delivered, not merely written onto the timeline, and it reports its delivery outcome in the same place and the same shape a hand-typed reply does.
• Internal note — add a note for your own team. A note is written to the timeline and, by design, is never delivered anywhere. This is the action to use for the "what the automation just did and why" breadcrumb that helps whoever picks the ticket up next.
• Set status — move the ticket to open, pending, on hold, solved or closed. Note that spam is not available as a macro action.
• Set priority — set low, normal, high or urgent.
• Add tag — add a label to the ticket.
• Assign agent — give the ticket to a specific person.
• Route to team — put the ticket on a team. Because this is a real routing action, it also triggers that team's automatic-assignment strategy, so a macro that routes to a team using round robin or load balancing will also produce an individual assignee.

An action that would not change anything is recorded as having been applied but not having changed the ticket. Applying a macro that sets a ticket to pending when it is already pending is harmless.

In the Studio, macros are managed under Settings → Ticketing → Macros, where the actions are an ordered list you build up, and applied to a ticket from the Apply macro control in the reply composer.

Macro reply text is literal. There is no placeholder or variable substitution, so what you type into a macro's reply is exactly what the customer receives, and you should write it to read correctly without any per-ticket personalisation.

Applying a macro by hand

Any editor can apply a macro to a ticket. The actions run in the order the macro lists them, and everything the macro does is recorded on the ticket's timeline, marked with the macro it came from. That provenance is important: months later you can tell whether a ticket was set to pending by a person or by a macro.

Triggers

A macro can also carry a trigger, which makes it fire automatically. In the macro editor this is the Run automatically option. There are two trigger events: create, when a ticket is first created, and update, when a ticket is written to.

A trigger can carry conditions, and the macro fires only when all of them match. A condition reads one field, applies one operator, and compares against one or more values.

The fields you can test are status, priority, source, team, assignee, tag and subject.

The operators are is, is not, is any of (matches any value in a list), is none of, is set, is empty, and contains. The value forms follow the operator: in and not in take a list, is set and is unset take no value at all, and the rest take a single value. A mismatched combination is rejected when you save the macro rather than silently misbehaving later, and there are limits on how many conditions one trigger may carry and how long each value may be.

This is enough to express most routine routing. "When a ticket is created with source email and the subject contains invoice, route it to Billing and set priority high" is one macro with two conditions.

How automatic firing behaves

The behaviour of triggered macros is worth understanding, because it is what stops automation from running away with itself.

Selection happens once, against one snapshot of the ticket. After a ticket is written, Auralis looks at the ticket's resulting state, picks every enabled macro whose trigger covers that event and whose conditions match, fixes the order, and applies them. It does not re-examine the ticket between applications.

Three consequences follow, and all three are good ones:

Macros cannot loop. A change made by a triggered macro cannot cause the selection to run again, because selection has already finished by the time any macro runs. A macro that would trigger itself, or two macros that would trigger each other, simply stop. Each selected macro is applied at most once per ticket per write.

The order is predictable. Macros run in the order they were created, oldest first. Because the order is fixed before any of them run, it cannot depend on which fields an earlier macro happened to change.

One failing macro does not damage the others. Each macro application runs in its own transaction, opened after the write that triggered it has already committed. A macro that fails rolls back only itself; the ticket create or update that triggered it still stands, and the other macros still run.

Every event a triggered macro writes is marked as automatic and records which write set it off, so an automatic action is always distinguishable from a click.

Managing macros

Editors create, edit and apply macros. Deleting a macro is an admin action, because a macro is shared equipment and deleting one silently changes what everybody else's tickets do.

Two habits are worth adopting. Disable a macro before deleting it, and give it a few days — if nobody notices, it really was unused. And when writing a triggered macro, write the conditions first and leave the trigger off until you are confident they select what you think they select; a macro with no trigger is a macro you can test by hand on a real ticket without any risk of it firing across the queue.