Workflows

A workflow works tickets without a technician. It can nudge a client who went quiet and solve the ticket a few days later, escalate an urgent ticket nobody touched for a day, open a backup check ticket for every client each month, or open a review ticket when one endpoint keeps raising tickets. This page explains what a workflow is made of and the safeguards around it. To build one, see Build a workflow.

Where to find workflows

Console	Where
MSP plan, practice view	Inbox > Workflows. Workflows are built here, once for the practice.
MSP plan, inside a client	Tickets > Workflows. Shows that client’s older rules and a read-only list, Practice workflows that apply here.
Enterprise	Tickets > Workflows.

Workflows is in the navigation only for people who hold automation:manage. The owner and the Support Manager role hold it. See Roles and permissions.

What a workflow is made of

A workflow is a form with these parts, in this order:

1. Trigger: what makes it run.
2. Clients: which clients it runs in. MSP plan only.
3. Conditions: which tickets it acts on.
4. How often: how many times it may act on one ticket.
5. When it runs: the hours it may act in.
6. Steps: what it does, in order, with optional If/Else branches.

Each part is described below. Every option and limit is listed in the Workflow reference.

Triggers

Trigger	Runs	Use it for
When something happens to a ticket	When a ticket is created, updated, or replied to.	Routing and tagging new tickets, reacting to a client reply.
Keep checking open tickets	Every 5 minutes, over open tickets and tickets solved within the last 90 days.	Time-based work: “waiting on the client for 3 days”, “untouched for 24 hours”, “close solved tickets after 7 days”.
On a schedule	Daily, weekly, monthly, or on a cron expression, in a time zone you choose. Each run happens once in every client in scope.	Recurring tickets, such as a monthly backup check.
When tickets pile up	Every 5 minutes, counting recent tickets that share an endpoint or a requester.	Spotting a repeat problem, such as 3 tickets on one endpoint in 60 days.

A schedule or pile-up workflow has no ticket to act on, so its steps can only create tickets and notify your team.

Clients

Plans

MSP

On the MSP plan, a workflow is built once in your practice and runs in each client’s tickets. Choose All clients, Only these clients, or All clients except these. A client you add later is covered by All clients and All clients except these without editing the workflow.

Queues, groups, business schedules, and ticket templates belong to each client, so a workflow names them by name and looks each one up in the client it is running in. When a client has no item with that name, the step that uses it is skipped in that client, the run is logged, and the workflow shows a health warning. Give the item the same name in every client, or narrow the scope.

On Enterprise there is one organization, so there is no Clients card.

Conditions

Conditions decide which tickets the workflow acts on, such as “Status type is Pending and Time since our last public reply is at least 3 days”. Combine them with all or any groups. A workflow with no conditions acts on every ticket its trigger finds. Schedule and pile-up workflows have no conditions: a pile-up workflow filters the tickets it counts instead.

How often

A workflow acts on each ticket Once per ticket unless you choose otherwise. This stops a workflow that keeps checking open tickets from acting on the same ticket every 5 minutes.

Choice	What it does
Once per ticket	The default. Acts on a ticket the first time it matches, and never again.
A few times per ticket	Acts up to 2 to 10 times, with at least the time you set between runs.
Repeatedly while it matches	Acts again each time the interval passes, for as long as the ticket matches. Only for Keep checking open tickets.
Every time	Acts on every matching event, with no limit. Only for When something happens to a ticket.

With Once per ticket or A few times per ticket, you can also select Start counting again when the ticket stops matching. A ticket that stops matching, such as a client who replies, then starts again with a clean count the next time it matches.

When it runs

Choice	What it does
Any time	The default.
During a business hours schedule	Acts only inside the hours of the business schedule you name.
During the ticket’s SLA hours	Acts only inside the schedule of the ticket’s SLA policy, or the client’s default schedule when the ticket has no running SLA timer.

Outside the hours, the workflow does not act and the run is logged as Outside its run window. A workflow that keeps checking open tickets acts on its first check inside the hours. A ticket event that happens outside the hours is skipped. Schedule workflows have no When it runs card, because the schedule already sets the time.

See Service level agreements for business schedules.

Steps

Steps run in order. A step can change a field, add or remove a tag, add an internal note, send an email, call a webhook, notify people, create a ticket, branch with If / Else, or ask AI to choose an answer.

• If / Else runs its Then steps when a condition is true, or when an AI step chose one of the answers you pick, and its Else steps otherwise. Branches nest up to 3 levels deep.
• Notify people sends your team a notification in the console bell, and sends the requester, people copied on the ticket, and the client’s primary contact an email. See Notifications.
• Ask AI reads the ticket, chooses one of the answers you list, and can write an internal note, add tags from your list, and write a draft reply a technician reviews. It cannot email the client. See AI steps in workflows.

Run order

Workflows run in Run order, lowest first. A later workflow sees what earlier ones changed. When two have the same run order, older client rules run first, then workflows in name order.

Safeguards

Safeguard	What it does
Test	Runs the draft against real tickets and shows what it would do, without changing anything, sending email, or calling AI. The console asks for a test before you turn a changed workflow on.
Pause all workflows	One switch on the Workflows page that stops every workflow and every client’s older rules until it is turned off.
Action limit	A workflow that takes more than 200 actions in an hour, across all clients, is paused automatically, raises an alert, and notifies everyone with automation:manage. You can change the limit under Safety limits.
Client email limit	Workflow steps send at most 3 emails about one ticket in a UTC day. Further email steps on that ticket are skipped until the next day. You can change the limit under Safety limits.
AI failure pause	A workflow whose AI step fails 5 times in an hour in one client is paused automatically.
Health warnings	A workflow that cannot do everything it is set to do shows Needs attention, with the reason.
Conflict warnings	Saving a workflow that sets the same field on the same trigger as another enabled workflow saves it and warns you.
Runs tab	Every run, skip, fallback, and failure, with the reason and the steps taken.
Ticket history	Every ticket a workflow acts on records the workflow’s name.

Each of these is covered in Build a workflow.

Older client rules

Automation rules created before workflows keep running unchanged. They are listed on the Workflows page with their client’s name beside them, and on each client’s Workflows page under Rules for this client. You can turn them on or off, edit them, and delete them. You cannot create new ones: build a workflow instead.

A rule opens in the same builder in rule mode. Rule mode keeps a rule’s original abilities: one event or the 5-minute check, conditions, and the original six actions. To use If/Else branches, AI, a schedule, a pile-up trigger, or more than one client, build a workflow.

Related

• Build a workflow
• AI steps in workflows
• Workflow reference
• Notifications
• Service level agreements