Ticket Automation Rules

Automation rules do ticket work for you. This guide takes you from nothing to a working rule: what you need before you start, a click-by-click quick start for each of the two rule kinds, and then the full reference — every field, every template, how to read the run log, and what to check when a rule doesn't fire. If you only read two sections, read Quick start: your first traditional rule and Why didn't my rule fire?.

Before You Start

Automation rules live at Settings → Automation rules in the admin sidebar (under the Ticket setup group). You need an administrator account — the page requires the automation:manage permission, which tenant admins and owners hold by default.

There are two kinds of rule, and they have very different requirements:

Traditional rule AI worker rule
Admin access Required Required
An AI agent Not needed Required — an agent with the Automation specialty (create one in two minutes, from inside the rule wizard if you like)
A connected automation runner Not needed Required — the page's health banner tells you whether one is connected (details)
AI credits Not needed — traditional rules are free Required — usage is metered per rule (AI Credits & Billing)
Fastest path to value

Traditional rules need no setup at all. If you're new to automation, do the traditional quick start first — you'll have a working rule in five minutes and you'll have learned the page. Come back for the AI setup afterwards.

Setting Up for AI Worker Rules

Three things must be true before an AI worker rule can run. Do them once; every AI rule after that just works.

1. Have an AI agent with the Automation specialty

An AI worker rule doesn't pick a model — it picks an agent: a named configuration that carries a persona prompt, a model binding, and optionally attached knowledge bases. You have two ways to get one:

What goes in the agent vs. what goes in the rule

Keep the agent's persona prompt broad and stable: who the worker is, house style, what it must never do. The default quick-create persona — an automation worker that follows per-rule instructions precisely and keeps its notes short — is fine to ship with. The specifics of each job go in the rule's Instructions field. One agent can serve many rules; each rule tells it what to do on those particular tickets.

2. Confirm the automation runner is connected

AI worker rules are executed by an automation runner — a worker process connected to your account that picks up tickets and works them. Traditional rules run inside the platform itself and never need one. The Automation page tells you plainly which state you're in, in a banner at the top:

Banner What it means What to do
"Automation runner connected" A live runner is checked in. AI rules will pick up tickets. Nothing — you're set. The banner also shows when the runner was last seen.
"No automation runner is connected" AI worker rules are configured but no runner has checked in — those rules will not run. Traditional rules still work. On RapiDesq-hosted plans the platform runner connects for you — if this persists, contact support. Self-managed fleets provision their own runner with an agent token; see your deployment runbook.
"No ticket webhook is registered" The runner is connected but only wakes on its periodic poll, so pickups can lag by up to a minute. Harmless for most workloads. Register the webhook (runner configuration) for instant pickup.
"Nothing is automated yet" No rules exist. Do a quick start below.

3. Have AI credits

AI workers spend AI credits as they work, attributed to the individual rule so you can always see which automation is spending. If the balance runs out mid-job the worker parks the ticket and records an Out of credits run — it never fails silently. Traditional rules cost nothing, ever.

Quick Start: Your First Traditional Rule

Goal: new billing tickets get routed to the right team automatically. No AI, no setup, free. Five minutes.

  1. Go to Settings → Automation rules and press New rule.
  2. The template gallery opens ("Start from a template — pick the outcome you want"). Choose Auto-assign new billing tickets and press Continue. The wizard opens pre-filled; a note on the Review step will remind you it started from this template, and nothing is locked.
  3. Scope step. Give the rule a name your team will recognise (the template pre-fills one) and, if you want, narrow it to one team or one ticket type. Leaving scope as Any makes it account-wide. Press Next.
  4. Trigger step. The template selects Ticket created — "runs once, right after a new ticket is created." Leave it. (The other triggers — status changed, field changed, sitting in a status too long, on a schedule — are covered in the reference.)
  5. Conditions step. This is how the rule knows a ticket is a billing ticket. The template pre-fills a condition; point it at your own data, e.g. Ticket type is Billing. Conditions combine with ALL/ANY, and no conditions means the rule runs on every trigger.
  6. Actions step. Actions run top to bottom. Set Assign to a team to your billing team, and keep or adjust Set priority. Add more with Add an action — tag it, post an internal note, notify the team.
  7. Schedule step. Leave Always active. (You can bind a rule to run only during — or only outside — a business-hours schedule.)
  8. Review step. The wizard states the rule back to you as one sentence — "When a ticket is created and Ticket type is Billing, assign it to Billing Team and set priority to High." If that sentence isn't what you meant, the rule isn't either. Press Create.
  9. The rule appears in the list, Active, with last run "Never ran".
  10. Prove it works: create a ticket that matches (any channel). It lands already assigned; its timeline attributes the change to automation; and the rule row now shows a last run. Press View run log on the rule to see the run, its trigger source, and each action it took.

Quick Start: Your First AI Worker Rule

Goal: every new bug gets investigated and written up by an AI worker before a human touches it. Assumes the runner banner is green; the agent can be created inside the wizard.

  1. On Settings → Automation rules, check the health banner reads "Automation runner connected." If it doesn't, fix that first — the rule would save fine but never run, and the page will tell you exactly that.
  2. Press New rule and pick Triage new bugs with AI from the gallery — "an AI worker investigates every new bug, augments it with knowledge-base context, and finds and links duplicate reports."
  3. Scope step. Name it, and scope it to the team or ticket type that receives bugs. A chip shows the rule's kind (AI worker) — kind is fixed at creation.
  4. Lane step. "A lane is the statuses the worker picks tickets up from, and the status it drives them to." The template watches your first open status and drives to an in-progress status — shown visually as watched statuses → drives to → target. Adjust to your workflow's statuses. Order matters: the top watched status is checked first.
  5. Agent step. Pick your automation agent. No agent yet? Use the inline quick-create: type a name and press Create agent — it creates a managed Automation agent and selects it. (You'll refine its persona and knowledge bases later under AI settings.)
  6. Still on the Agent step, write the Instructions for the worker — the most important field on the rule. The step's guidance panel tells you what the worker can see (subject, description, custom fields, recent activity, the agent's knowledge bases) and what it can do (investigate, search other tickets, comment, link, update fields, move the ticket). The template pre-fills triage instructions; a good pattern to copy:
    "Summarize what this request means using the project glossary in the knowledge base. Search for open tickets describing the same problem; if you find one, link it as a duplicate, add a comment referencing it, and note the report count. Post an internal note with your findings and what information is still missing. Do not contact the customer."
    Say what "done" looks like, what to write down, and when to stop.
  7. Limits step. The guardrails per ticket: Maximum hops (how many advances one worker may make before releasing the ticket), Token budget and Time budget (spend and wall-clock ceilings), and Keep the same worker across hops (sticky). For a one-step triage job: sticky off, max hops 1, a modest token budget. Whichever limit hits first ends the job cleanly and records why.
  8. Schedule step — leave Always active, then Review: "When a Bug ticket in New needs work, an AI worker using Automation Worker will drive it to In Progress, spending at most your budget." Press Create.
  9. Prove it works: create a bug ticket in a watched status. Within moments (or up to a minute on poll-only setups) the worker claims it, posts its triage note on the timeline, advances the ticket, and releases it. The rule row shows the last run; View run log shows the carry — when it started, hops taken, tokens spent, outcome Completed.
Run any new rule scoped for a day

Keep a new rule pointed at one team or one ticket type, watch its run log for a day, then widen the scope. The log records every run and every reason a run didn't happen, so you'll know quickly whether it does what you meant.

The Two Kinds of Rule

Support work has two very different shapes of repetition. Some of it is mechanical: every urgent billing ticket should go to the Tier 2 team and get tagged. Some of it needs judgment: every new bug should be investigated and written up before anyone triages it. RapiDesq gives you one automation surface with a rule kind for each.

AI worker rule (an "AI lane") Traditional rule
What acts An AI worker, using the same ticket tools a person has. The platform itself — a fixed list of actions.
What starts it A ticket entering one of the statuses the lane watches. A trigger: ticket created, status changed, field changed, a dwell timer, or a schedule.
What it does Works the ticket and advances it, repeatedly, toward a target status. Runs your actions in order, once.
Predictability Judgment-based — results vary with the ticket. Completely deterministic.
Setup needed Agent + runner + credits (above). None.
Cost Consumes AI credits, attributed to the rule. Free — no model is called.
Which kind should I use?

Reach for a traditional rule first. If a fixed set of actions gets the job done, it is predictable, instant, and costs nothing. Use an AI worker when the step genuinely needs judgment — reading a conversation, investigating, deciding, or writing something a person would otherwise have to write.

Core Concepts

Scope

Every rule can be narrowed to a team, a ticket type, both, or neither. Leaving both as Any makes the rule account-wide. Scope is the cheapest way to keep a new rule contained while you build confidence in it — start it on one team, then widen.

Watched statuses are lanes

An AI worker rule names an ordered list of watched statuses and one target status. Picture each watched status as a lane on a conveyor: a ticket arriving in any of them is work the lane's AI worker is expected to pick up and push toward the target.

Sticky carry-through

With Keep the same worker across hops switched on (the default), a worker that advances a ticket checks whether the new status is also one it watches. If it is, the same worker keeps the ticket and continues in the same session rather than handing it back and being re-assigned — one worker walks the ticket through several statuses, retaining the context of what it just did. Switch it off when each status should be handled as an independent piece of work.

Budgets

Each carry is bounded three ways — by status advances (Maximum hops), by tokens, and by time. Whichever limit is reached first ends the carry cleanly: the worker releases the ticket and records why it stopped. Nothing is lost; the ticket simply goes back to being ordinary work. Budgets are your spend ceiling per ticket — the reason an AI lane cannot quietly run up a bill on one difficult ticket.

Priority class and takeover

A lane is either Normal or Takeover. Normal work queues behind whatever the fleet is already doing. Takeover work pre-empts it: a lower-priority worker finishes the step it is on, saves its place on the ticket, releases it, and hands its capacity to the urgent item. Nothing is abandoned mid-step. Use Takeover sparingly — for genuinely urgent lanes such as outage escalations.

Agents and instructions

An AI worker rule is bound to an AI agent, which supplies the persona and the model tier. The rule adds an Instructions for the worker box describing what this particular rule should accomplish. You never pick a model on the rule — change the agent if you want different model behavior, and the change applies everywhere that agent is used.

Conditions and schedule windows

Both kinds of rule accept optional conditions (ALL/ANY checks on the ticket) and an optional business-hours window that either restricts a rule to a schedule or suppresses it during one. A rule skipped because of its window records that fact in the run log — it is never a silent no-op.

AI Worker Rule — Field Reference

Wizard steps: Scope → Lane → Agent → Limits → Schedule → Review.

Field What it does Default
Name How the rule appears in the list and in the run log. —
Active Whether the rule runs. Turning it off keeps the rule and its history. On
Team / Ticket type Narrows the rule. Any means no restriction. Any
Watched statuses Ordered list of statuses whose arrivals the lane picks up. Top is highest priority. —
Target status Where the worker is trying to get the ticket to. It stops when the ticket lands here. —
AI agent The agent that runs this lane. The agent carries the model binding — there is no model to pick here. —
Instructions for the worker What this rule's worker should actually do, in plain language. Combined with the agent's own persona. The most important field to get right. Empty
Keep the same worker across hops Sticky carry — keeps one worker (and its context) when the next status is also watched. On
Maximum hops How many times the worker may act on one ticket before it gives up and releases it. 10
Token budget / Time budget Spend and wall-clock ceilings for one carry. Blank = no limit. Platform defaults
Priority class Normal, or Takeover to pre-empt workers running normal-priority rules. Normal
Business-hours window Always active / only during a schedule / paused during a schedule. Always active

Traditional Rule — Field Reference

Wizard steps: Scope → Trigger → Conditions → Actions → Schedule → Review.

Triggers

Trigger Fires when Typical use
Ticket created Once, right after a new ticket is created on any channel. Intake routing, first-touch tagging.
Status changed A ticket moves into one of the statuses you pick. Escalation, notification on hand-off.
Field changed One of the ticket fields you name changes. React to a custom field being filled in.
Sitting in a status too long A ticket has sat in one of the statuses you pick longer than the minutes you set. Stale-ticket nudges, auto-close after N days.
On a schedule A cron schedule fires and sweeps every matching ticket (e.g. 0 9 * * MON = Mondays 09:00). Weekly backlog sweeps.

Triggers also carry "Also fire on automation-made changes" — off by default, and leaving it off is what stops two rules from triggering each other forever (see loop safety).

Conditions

Conditions combine with Match ALL / Match ANY (groups can nest) and can test priority, ticket type, team, channel, tags, workflow status, custom field values, ticket age in minutes, subject text, and whether a contact or assignee is present. Comparisons: is, is not, is one of, is none of, contains, does not contain, is empty, is not empty, is more than, is less than. No conditions means the rule runs every time its trigger fires. Keep condition groups small — a rule you cannot summarize in a sentence is a rule that will surprise you.

Actions

Actions run top to bottom. If one fails, the run stops there and records the error alongside the actions that already succeeded.

Action What it does
Set priorityOverwrites the ticket's priority.
Assign to a teamMoves the ticket to another team's queue.
Assign to a userAssigns the ticket directly to one person.
Add a tag / Remove a tagApplies or removes a tag, creating it if your account doesn't have it yet.
Move to a statusAdvances the ticket through your workflow, respecting every gate (see below).
Post an internal noteAdds a team-only note to the timeline. Supports {{ticket.*}} placeholders.
Send a notificationNotifies the team, the assignee, or specific users.
Set a custom fieldWrites a value into one of your ticket custom fields.
Advancing status respects your workflow — automation never fakes a gate

If a transition carries a Definition of Done requirement, a traditional rule will only take it when it passes on its own. It never fabricates evidence and never forces a transition. A blocked attempt is recorded in the run log as Gate blocked, with the reason, so you can see it and decide. If the transition requires human approval, the rule leaves it pending for a person. This is deliberate: deterministic automation is not allowed to assert that work is done.

Templates

New rule opens a template gallery rather than a blank form — pick the outcome you want and the wizard opens pre-filled; adjust anything before saving. (Blank AI worker and blank traditional starts are at the bottom of the gallery under "Or start from scratch".)

Template Kind What it sets up
Triage new bugs with AIAI workerInvestigates every new bug, augments it with knowledge-base context, finds and links duplicate reports. Pre-fills full triage instructions.
AI drives docs tickets to doneAI workerA sticky lane that carries documentation tickets from to-do through to resolved, drafting as it goes.
Escalate urgent ticketsTraditionalWhen an urgent ticket starts moving: hand it to the escalation team, tag it, notify them.
Auto-assign new billing ticketsTraditionalRoute new billing tickets to the right team and raise their priority on creation.
Nudge stale ticketsTraditionalAfter two days waiting: post a note on the ticket and ping the assignee.
Close resolved tickets after 7 daysTraditionalMove resolved tickets to closed a week later, respecting every workflow gate.
Tag VIP contactsTraditionalTag new tickets from VIP contacts so they stand out in every queue.
Weekly backlog sweepTraditionalEvery Monday morning: raise the priority of week-old new tickets and notify the team.

Worked Examples

Example 1 — an AI lane that triages incoming bugs

Goal: every new Bug ticket gets investigated and written up before a human looks at it, and lands in In Progress ready to work. (This is the AI quick start in summary form.)

  1. Scope: team Engineering, ticket type Bug.
  2. Lane: watched statuses New; target status In Progress.
  3. Agent: your automation agent. Instructions: "Read the report and the conversation. Try to reproduce the issue from the details given. Post an internal note with what you found, the steps to reproduce, and what information is still missing. If the report is not actionable, say exactly what to ask the customer."
  4. Limits: sticky off (one hop is the whole job), max hops 1, a modest token budget.
  5. Review: "When a Bug ticket in New needs work, an AI worker using Support Agent will drive it to In Progress."

What you will see: a new bug arrives, the worker claims it, posts its triage note, advances it to In Progress, and releases it. The rule row shows the last run, and the run log shows the carry with one hop.

Example 2 — a traditional rule that escalates urgent billing tickets

Goal: an urgent billing ticket never waits in the general queue.

  1. Trigger: ticket created.
  2. Conditions: ticket type is Billing AND priority is Urgent.
  3. Actions: assign to team Tier 2 → add tag escalated → send a notification to the team.
  4. Window: always active (an urgent ticket at 2am still needs the tag).
  5. Review: "When a ticket is created and Ticket type is Billing and Priority is Urgent, assign it to Tier 2, add tag escalated, and notify the team."

Example 3 — the two kinds working together

A traditional rule moves aged tickets from Waiting to Needs Review and posts a note. An AI lane watches Needs Review, summarizes what happened and drafts a reply, and advances to Ready to Send. The deterministic rule handles the clockwork; the AI lane handles the writing. This is the recommended shape for most automation: cheap deterministic plumbing feeding narrowly-scoped AI work.

Loop Safety

Automation that changes tickets can, in principle, trigger more automation. RapiDesq bounds this for you, always, with limits you cannot accidentally disable — and it never does so silently.

When any of these trips, a breaker latches on that ticket: all automation on it pauses for 6 hours, a note is added to the ticket timeline explaining why, the run log records the trip with full detail, and the Automation page counts it in the health strip ("N tickets paused by the loop breaker"). Clear it early from the run log (Clear the loop breaker on this ticket) once the rules are fixed, or let it expire.

Every reason automation didn't act is written down

Blocked by a gate, waiting for approval, outside its window, conditions not met on a sweep, capped, cooling down, breaker tripped, out of credits — each is a run-log entry with a reason. Automation that quietly does nothing is the hardest kind to debug, so RapiDesq doesn't have any.

Run Log

View run log on any rule shows its 20 most recent runs: when each started, its trigger source (event, poll, sweep, takeover), the ticket, duration, hops (for AI lanes), and outcome:

Outcome Meaning
Succeeded / CompletedThe rule did what it was configured to do.
ReleasedAn AI worker finished its carry and handed the ticket back.
YieldedThe worker stepped aside for higher-priority takeover work.
Gate blockedA status advance was refused by a Definition of Done requirement.
Approval requiredThe transition is waiting on human sign-off.
Conditions not metA timed or scheduled rule matched a ticket, but its conditions did not.
Outside windowThe rule was outside its business-hours window.
Cap exceeded / Cooling down / Breaker trippedLoop safety stopped the run.
Out of creditsAn AI lane paused because the credit balance ran out.
ErrorAn action failed; the detail names which one.

The rule list itself shows each rule's last run time and last outcome, so a rule that has quietly stopped working is visible without opening anything.

Why Didn't My Rule Fire?

Work down this list — each check maps to something you can see on the page. In almost every case the answer is already written in the run log or the health banner.

Check Where to look Fix
Is the rule Active? The Active toggle on the rule row. Inactive rules stay configured but never run. Switch it on.
(AI rules) Is a runner connected? The health banner. Red = "No automation runner is connected." AI rules cannot run without one; see runner setup. Traditional rules are unaffected.
Did the ticket enter the watched status after the rule existed? The ticket's timeline. Lanes fire on arrival into a watched status. Tickets already sitting there when you created the rule aren't picked up — move one out and back in to test, or use a dwell-timer traditional rule for the backlog.
Does the scope match? The rule's Team / Ticket type scope vs. the ticket's. A rule scoped to team A never sees team B's tickets. Widen the scope or fix the ticket.
Did conditions fail? Run log — a Conditions not met entry. The rule ran and decided no. Compare the condition values against the actual ticket; remember ALL requires every condition to pass.
Was it outside its window? Run log — an Outside window entry. The business-hours window suppressed it. Adjust the Schedule step.
Did loop safety stop it? Health strip breaker chip; run log Breaker tripped / Cap exceeded / Cooling down; a "[automation] paused" note on the ticket timeline. Fix the rule interaction that looped (usually two rules reacting to each other — check "Also fire on automation-made changes"), then Clear the loop breaker on this ticket from the run log.
(AI rules) Out of credits? Run log — an Out of credits entry. Top up AI credits; the parked ticket resumes on the next pickup.
(AI rules) Was the advance gate-blocked? Run log — Gate blocked or Approval required. The worker did its job but your workflow's Definition of Done stopped the transition, by design. Supply the gate evidence, approve the transition, or adjust the workflow.
Nothing in the run log at all? The rule row shows "Never ran". The trigger genuinely never fired for a matching ticket. Re-check trigger type (e.g. Status changed needs a status you listed) and create a matching test ticket.

Automation Health

The banner at the top of the Automation page reports whether automation can actually run, using the exact states listed in runner setup: connected (with last-seen time and active rule counts), no runner connected, no webhook registered (poll-only pickup), or nothing automated yet. A chip counts tickets paused by the loop breaker in the last 24 hours. The banner exists so a configured-but-dead setup can never look healthy.

Credits and Cost

AI lanes consume AI credits per turn, attributed to the individual rule — so usage reporting answers "which rule is spending", not just "how much did AI cost". Per-carry token budgets are your ceiling per ticket. If the balance runs out mid-carry, the worker parks the ticket and records an Out of credits run rather than failing silently.

Traditional rules never call a model and consume no credits, no matter how often they fire.

Best Practices