Overview
Ticket Workflows are if-then rules that act on tickets automatically. Instead of manually triaging every new ticket — assigning a technician, setting priority, routing to the right department — you author rules once and let the system apply them.
A workflow watches for a specific event (like a ticket being created), checks whether the ticket matches the conditions you define, and if it does, runs the actions you've configured.
You can access the rule list from the main navigation under Support Center → Ticket Workflows.
To create or edit rules you need the Manage Ticket Workflows permission, found in the Help Desk permission category. This permission is independent of ticket-viewing permissions — granting it does not give the administrator access to ticket content.
When to use a workflow
Workflows are most useful when you find yourself doing the same triage step on every ticket. Common patterns:
- Auto-assign by topic — every ticket whose subject mentions "Chromebook" goes to your hardware tech
- Round-robin a queue — distribute incoming tickets evenly across a team of technicians
- Escalate urgency — when a ticket arrives with priority "High" and a custom field marked critical, bump it to the top of the queue and notify the team lead
- Department routing — tickets that mention "network" or "wifi" get reassigned from the general queue to Networking
- Default the assignee — for a department with one tech, every ticket lands on that tech without anyone clicking a button
If a step happens manually on most tickets, it's a candidate for a workflow.
The mental model
Every rule has the same shape:
When this trigger fires,
if these conditions match,
then run these actions.
Three parts make up a rule:
Trigger
The event that starts the rule. The rule only runs when this event happens. Three triggers are available:
-
New ticket opened (
ticket.created) — fires the moment a new ticket is submitted, whether through the user portal, an admin opening it on someone's behalf, or the inbound email pipeline. Most automation lives here: routing by topic, auto-assigning by department, escalating urgent keywords on arrival. -
Ticket updated (
ticket.updated) — fires when an admin changes a field on the ticket: priority, status, department, assigned admin, or subject. Useful for "if priority gets bumped to High, notify the lead" or "if the ticket moves to Network & WiFi, drop a checklist note for the receiving team." -
User replied (
ticket.replied) — fires only when an end user replies to a ticket (via the portal or by replying to a notification email). Admin replies don't fire this trigger. Common uses: re-open closed tickets when a user replies, or notify a tech when a customer responds while they're out of office. -
On a schedule (
ticket.scheduled) — fires every 15 minutes from a background cron task that evaluates against every currently-open ticket. This is what you reach for when you want a rule that responds to time passing rather than to a discrete event. Pairs with the Ticket age and Idle time condition types described in Building Conditions. The most common pattern is escalation: "if a high-priority ticket has been idle for 30 minutes, notify the team lead."Per-ticket cooldown is built in: a scheduled rule won't re-fire on the same ticket within 24 hours, so an "idle for 30 minutes" rule that's still true at the next sweep doesn't keep paging.
Conditions and actions on a rule see the post-event state of the ticket — for ticket.replied, status will already be User Replied by the time conditions evaluate; for ticket.updated, the new field values are in place. This means a condition like "status is Closed" on a ticket.replied rule never matches on a fresh user reply, because the reply itself bumps status off Closed first. Adjust the condition to test for the target of the change rather than the source.
Conditions
The "If" half. A list of tests that look at the ticket's content (subject, priority, department, custom field values, etc.) and return true or false. You decide whether all the conditions must match (AND) or any one (OR), and you can group conditions for more nuanced logic — see Building Conditions.
If the conditions don't match, the rule stops and does nothing. The ticket continues through the system unchanged.
Actions
The "Then" half. A list of things to do when conditions match — assign a technician, change the priority, reroute to a department, post an internal note, send a notification, and so on. Actions run in the order you list them. See Building Actions.
Anatomy of a rule
When you create or edit a rule, you'll work across five tabs:
- Settings — name, description, trigger, department scope, priority, and the on/off switch
- Conditions — the "If" half
- Actions — the "Then" half
- Test — run the rule against a synthetic ticket to verify it behaves as expected, before turning it on
- History — every time the rule has been evaluated, with the per-condition and per-action result so you can answer "why did this ticket land where it did?"
Rules can be saved in a half-finished state and toggled off until you're ready. A rule that's disabled is skipped by the engine entirely — there's no risk in having drafts sit alongside live rules.
How multiple rules interact
You'll often have several workflows running at once. Two settings determine how they coordinate:
Priority order
Each rule has a priority — lower numbers run first. The rule list lets you drag rules to reorder them, which rewrites their priorities to match the visual order. Rules with the same trigger evaluate in the order you've arranged them.
Department scope
Each rule can apply to all departments or to a specific list. A rule scoped to one department is skipped for tickets in other departments — which keeps department-specific automation from leaking into queues you didn't intend it for.
Stop actions
Some action types are terminal — the most common is the explicit Stop action. When a terminal action runs, the engine stops processing further rules for that ticket on that trigger. This is how you write a "first match wins" sequence: arrange the most specific rule on top, end it with Stop, and any general fallback rules below won't fire.
Business hours
The Settings tab on each rule has an Only run during business hours toggle. When on, the rule:
- Skips evaluation entirely outside the configured open window — no run-log row, no actions
- Wait actions inside the rule accrue their timer only during open hours, so a 2-hour wait queued at 6 pm Friday lands Monday at 10 am (8 am open + 2 hours of business time)
Business hours are configured at the top of the rule list — start time, end time, days of week, and a Holidays list. Defaults to Monday–Friday, 08:00–17:00 in the system timezone with no holidays.
Holidays close the day regardless of which weekday it falls on. Add specific calendar dates (one YYYY-MM-DD per line) for federal holidays, district-closure days, or one-off snow days. A rule with Only during business hours on, scheduled to evaluate on January 1st, won't fire if 2026-01-01 is in your holiday list — it'll wait until the next open business day.
This matters most for escalation rules built on the On a schedule trigger: without business-hours awareness, a "ticket idle 30 min → page on-call lead" rule would fire at 3 am on a Saturday for a ticket that came in late Friday, or at 4 am on Christmas morning. With it on (and holidays populated), the rule waits politely until the next open day.
How workflows interact with department auto-assignment
If you've configured department-level auto-assignment under Settings → Help Desk → Departments (random or round-robin assignment per department), that system continues to work alongside workflows. Workflows don't replace it — they layer on top.
The order of operations on every new ticket is:
- Department auto-assignment runs first — if the destination department is set to random or round-robin, an admin gets picked from that department's pool using your existing configuration.
- Workflows run second — every enabled rule whose trigger and department scope match the ticket evaluates in priority order.
- A workflow's Assign to admin or Round-robin assign action overwrites the department-level pick — the rule's choice wins because it ran last.
Practical implications:
- Existing setups keep working unchanged. A district with no workflows authored sees zero behavior change — the engine evaluates an empty rule set in microseconds and the department's auto-assignment is the only thing that touches the ticket.
- Workflows that don't reassign leave department behavior intact. A workflow that only sets priority or routes by department doesn't touch
admin_id, so whoever the department assigner picked stays assigned. - Workflow round-robin and department round-robin are independent. Each maintains its own pointer into its own pool. They don't share state — which is intentional, because workflow pools are usually narrower (a specific tier-1 squad, a hardware specialist team) than the entire department's eligible admin list.
Use department auto-assignment for "spread tickets across this whole queue evenly." It's the default, applies to every ticket in the department, and doesn't need any conditions.
Use a workflow when assignment depends on what the ticket is about (subject, custom fields, priority), not just which department it landed in. "Network tickets that mention 'down' go to the on-call rotation, everything else round-robins to Tier 1" needs a workflow — department-level assignment can't see into the ticket content.
If a workflow always reassigns tickets in a given department, you can set that department's auto-assignment to None to skip the redundant first-pick. It's not required (the second pick wins anyway), but it removes a bit of churn in the audit log.
Testing before you go live
Before enabling a rule on real tickets, the Test tab lets you build a synthetic ticket — pick a subject, a department, a priority, fill in any custom fields the rule cares about — and dry-run the rule against it. The result panel shows which conditions matched, which actions would have run, and whether the rule would have fired overall. No tickets are created and no actions are executed during a test.
What happens after a rule fires
Every evaluation — match or no match — is recorded in the rule's run history. The History tab shows when the rule ran, which ticket triggered it, the result of each condition, and the outcome of every action. If you ever ask "why did this ticket end up assigned to that tech?", run history is where you'll find the answer.
History is per-rule and shows the most recent evaluations first.
Common Questions
Q: Will a workflow fire on tickets that already exist when I create the rule? No. Rules only run on the trigger event going forward. Tickets created before the rule was saved are not retroactively evaluated.
Q: Can I disable a rule temporarily without losing it? Yes. Each rule has an enabled/disabled toggle on both the rule list and the editor. Disabled rules are skipped completely until re-enabled.
Q: What if two rules try to assign the same ticket to different technicians? Both rules run in priority order. The second assignment overwrites the first. If you want the first match to win, end the higher-priority rule with a Stop action.
Q: Can I see what a rule did to a specific ticket? Yes. Open the rule, switch to the History tab, and look for the row matching that ticket. Each row expands to show every condition's result and every action's outcome.
Q: Do workflows work for tickets opened by email? Yes. The Ticket Created trigger fires regardless of how the ticket was opened — user portal, admin-on-behalf-of, or the inbound email pipeline.