---
title: "Workflows"
description: "Change tickets, notify people, and open tickets without a technician, on a ticket event, on a 5-minute check, on a schedule, or when tickets pile up."
url: "https://support.outpostplatform.com/service-desk/workflows/"
product: "depot"
type: "concept"
status: "draft"
ai_summary: "Workflows (Enterprise and MSP, automation:manage) work tickets without a technician. Triggers: a ticket event, a 5-minute check, a schedule, or tickets piling up. Parts: client scope (MSP), conditions, How often (once per ticket by default), When it runs, and steps with If/Else and AI. Safeguards: Test, Pause all, runaway auto-pause, client email cap, health warnings, and a Runs tab."
availability:
  plans: ["enterprise", "msp"]
  permission: "automation:manage"
  preview: false
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/service-desk/workflows.mdx"
license: "CC BY 4.0"
---

# 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](/service-desk/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](/depot/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](/service-desk/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

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](/service-desk/sla/) 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](/depot/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](/service-desk/workflow-ai-steps/).

### 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](/service-desk/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](/service-desk/build-a-workflow/)
- [AI steps in workflows](/service-desk/workflow-ai-steps/)
- [Workflow reference](/service-desk/workflow-reference/)
- [Notifications](/depot/notifications/)
- [Service level agreements](/service-desk/sla/)