Automation

Desk Center → Automation (administrators only)

A rule says what should happen to work without anybody doing it: assign a ticket as it arrives, move it on when something happens, fill in a field that is always the same.

Rules run at three moments:

When	What it means
An item is created	Somebody typed it, or a call's wrap-up filed it. Both count.
An item moves to a status	Any real move. Re-saving the same status is not a move.
A disposition is recorded	A wrap-up landed on work that already existed.

Rules act on work that already exists

They do not decide where work arrives. The queue decides which board a call lands on (Call routing) and the disposition decides whether a call leaves work behind at all. Automation is what happens next.

The order is the rule

Rules run from the top down, and the first rule to decide something wins. The first one to assign owns the assignee; the first one to move owns the status; the first one to write a field owns that field.

That is why the order is yours to set, with the arrows beside each rule. It also gives you the pattern every account ends up wanting:

1. The specific rules first — invoices to Ana, complaints to the supervisor.
2. The catch-all last — everything else to the pool.

A general rule placed at the bottom cannot steal work from the specific ones above it.

Writing a rule

Each rule has three parts.

When — one of the three moments above.

If — conditions, all of which must hold. You can test the board, the type, the priority, the status, the disposition the call was wrapped up with, and the queue it came through.

A rule with no conditions applies to everything of that moment. That is a real thing to want, and also the easiest rule to write by accident — which is what the next section is for.

Then — what it does:

• Assign to somebody,
• Move to status,
• Set field.

Try it before you save it

The two ways a rule goes wrong are matching everything and matching nothing, and neither looks wrong on the screen. Try it against recent work answers with both numbers — "would have matched 34 of the last 200 items on Support" — because 34 means opposite things out of four items and out of two hundred.

It is an estimate of the present: it asks how many of the items on that board would match today, not what they looked like when they were created.

What a rule will not do

It will not assign work to somebody who cannot read that board. If a board is restricted to a named list (Who Sees What) and a rule hands its work to somebody outside the list, the assignment is refused and the item is created unassigned. Work nobody can open is worse than work nobody owns.

It will not move an item along a transition the board forbids. If the board restricts where work can move, a rule obeys that restriction exactly as a person does.

It will not run for ever. A rule that moves an item fires the rules for moving, which can move it again. After a few moves in a row Desk Center stops and writes that into the item's history, so a chain that surprised you can be read rather than guessed at.

Everything a rule does is on the record

Every change a rule makes is written into the item's history, naming the rule. An item that changed column with nothing saying why is the thing people stop trusting automation for, so there is always a line that says which rule did it.

Switch a rule off instead of deleting it

A rule that misfires is stopped with one click and read afterwards. Deleting it loses the evidence of what it did.

What is not here yet

• Rules that run on a timer. "Nothing has happened for three days" is not something a rule can notice yet.
• SLA policies.
• Notifying somebody as an action of its own. Assigning already notifies the person it assigns to.