---
title: "Build a workflow"
description: "Build a workflow or start from the library, test it against real tickets, turn it on, and check what it did on the Runs tab and in ticket history."
url: "https://support.outpostplatform.com/service-desk/build-a-workflow/"
product: "depot"
type: "how-to"
status: "draft"
ai_summary: "How to build a workflow: Start from library or New workflow, set Trigger, Clients (MSP), Conditions, How often, When it runs, and Steps, then Run a test (changes nothing), turn it on, and read the Runs tab and ticket history. Also Duplicate, Delete, Pause all workflows, Resume after an automatic pause, health and conflict warnings, and editing an older rule."
availability:
  plans: ["enterprise", "msp"]
  permission: "automation:manage"
  preview: false
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/service-desk/build-a-workflow.md"
license: "CC BY 4.0"
---

# Build a workflow

This page shows how to build a [workflow](/service-desk/workflows/), test it
against real tickets, turn it on, and check what it did. When you finish, the
workflow is running and you know where to look when it does something you did
not expect.

## Before you begin

- Your plan must include the service desk: Enterprise or MSP. See
  [Plans and limits](/account/plans-and-limits/).
- You need `automation:manage`. See
  [Roles and permissions](/depot/roles-and-permissions/).
- To limit a workflow to business hours, create the business schedule first.
  See [Service level agreements](/service-desk/sla/).
- To use an AI step, set up AI first. See
  [AI steps in workflows](/service-desk/workflow-ai-steps/).
- On the MSP plan, build workflows in the practice view. A workflow's
  queues, groups, schedules, and templates are looked up by name in each
  client, so check the names match across the clients in scope.

## Start from the library

The library holds six working workflows. Starting from one is the quickest way
to see how the parts fit together. The six are listed in the
[Workflow reference](/service-desk/workflow-reference/#starter-library).

1. Select **Inbox** > **Workflows** on the MSP plan, or **Tickets** >
   **Workflows** on Enterprise.
2. Select **Start from library**.
3. Select **Add** beside the one you want. Library workflows marked **Uses
   AI** need AI set up before their AI step does anything.

The workflow is added turned off and scoped to every client, and opens in the
builder. Adjust it, test it, then turn it on.

**Start from library** is on the practice view only. A library workflow you
already added shows **Added**, and its button reads **Add another**. A second
copy is named with **(2)** after the library name, a third with **(3)**, and so
on.

## Build a workflow

1. Select **New workflow**.
2. Under **Details**, enter a **Name** and an optional **Description**.
3. Under **Trigger**, choose how it runs:
   - **When something happens to a ticket**: select **created**, **updated**,
     **replied to**, or more than one.
   - **Keep checking open tickets**: nothing more to set.
   - **On a schedule**: choose **Every day**, **Every week**, **Every month**,
     or **Advanced (cron)**, then the day, the time in **At**, and the **Time
     zone**.
   - **When tickets pile up**: choose whether the tickets share **An
     endpoint** or **A requester**, then **At least** (2 to 50 tickets),
     **Within days**, and **Then wait days**. Under **Only count tickets**,
     narrow what is counted by priority, status, type, or tags.
4. MSP plan: under **Clients**, choose **All clients**, **Only these clients**,
   or **All clients except these**, and select the clients.
5. Under **Conditions**, add the conditions a ticket must meet. Leave it empty
   to act on every ticket the trigger finds.
6. Under **How often**, leave **Once per ticket** or choose another. See
   [How often](/service-desk/workflows/#how-often).
7. Under **When it runs**, leave **Any time** or choose a schedule.
8. Under **Steps**, select **Add step** and choose a step. Fill in its fields.
   Repeat for each step. Use **Up**, **Down**, and **Remove** to arrange them.
9. Optional: under **Details**, enter a **Run order**. Lower runs first.
10. Select **Create workflow**.

The workflow is saved turned off. When something cannot be saved, the console
lists each problem under **Fix these problems to save** and marks the field.

### Add a branch

1. Select **Add step** > **If / Else**.
2. Choose what the branch depends on:
   - **A condition**: build the condition.
   - **The AI's answer**: choose the **AI step** and select the answers that
     take **Then**. This needs an **Ask AI** step earlier in the workflow.
3. Under **Then** and **Else**, add the steps for each branch.

Branches nest up to 3 levels deep. A workflow holds up to 50 steps.

### Use placeholders

In a subject, message, or note, select **Insert placeholder** (or **Insert in
subject** and **Insert in message**) to add a value such as
`{{ticket.reference}}` or `{{client.name}}`. The menu offers only the
placeholders the trigger can fill. See
[Placeholders](/service-desk/workflow-reference/#placeholders).

## Test the workflow

A test runs the draft on the screen against real tickets and changes nothing.
No email is sent, no ticket is created, and no AI is called.

1. On the **Test** card, select **Run a test**.
2. Read the result. It shows how many tickets match and, for each client and
   ticket:
   - **Steps**: the steps it would take;
   - each field change, as the old value and the new one;
   - **Tells**: who it would notify or email, with **(none on this ticket)**
     beside a recipient the ticket does not have, such as a requester with no
     email address;
   - **Would create**: tickets it would open;
   - **Skipped**, with the reason, when it would not act.

For a workflow that runs when something happens to a ticket, the test treats
the 25 most recent tickets in each client as if the event had happened to
them. A test shows at most 25 matches in each client and 200 in total. An AI
step is not run in a test, so both of its outcomes are possible.

Change the draft and test again until the result is what you want. The card
says **The draft changed since this test.** when the result is out of date.

## Turn it on

1. Under **Details**, turn on **Enabled**.
2. Select **Save**.

If the workflow changed since its last test, the console asks **Turn it on
without a test?** Select **Run a test first**, or **Turn on anyway**.

You can also turn a workflow on or off with its switch on the **Workflows**
page.

## Check what it did

### Runs tab

Open the workflow and select **Runs**. Each row shows **When**, the
**Client** on the MSP plan, the **Ticket**, the **Outcome**, and **What it
did**: the steps it took, the AI step's answer or fallback, and any tickets it
created. Filter by **Client** and **Outcome**.

| Outcome | Meaning |
| --- | --- |
| **Ran** | The workflow acted. |
| **Skipped** | It considered the ticket and did not act. The reason is shown, such as **Already ran as often as allowed** or **Outside its run window**. |
| **Failed** | It could not finish. The error is shown. |
| **Stopped by a loop guard** | Outpost stopped it to prevent a loop between workflows. |
| **Took the AI fallback** | An AI step did not answer, and its fallback steps ran. The reason is shown. |

A workflow that keeps checking open tickets records nothing for a ticket that
does not match. Every reason is listed in the
[Workflow reference](/service-desk/workflow-reference/#run-outcomes-and-reasons).

### Ticket history

A workflow that acts on a ticket adds an internal line to the conversation,
such as **Workflow "Waiting on client: nudge, then close" ran.**, signed with
the workflow's name. On the ticket's **Activity** tab, each change it made
carries a chip with the workflow's name. Older client rules do the same.

## Duplicate or delete a workflow

- To copy a workflow, select **Duplicate** in its row. The copy is named
  **Copy of** followed by the original name, and is turned off.
- To delete one, select **Delete** in its row and confirm. Whatever it was
  doing stops happening.

## Pause every workflow

Turn on **Pause all workflows** at the top of the **Workflows** page. It
stops every workflow and every client's older rules until you turn it off.
Nothing is lost, and while it is on, tickets are worked by hand. Ticket events
during the pause are skipped, not replayed later.

## Resume a paused workflow

Outpost pauses a workflow on its own in two cases:

- It took more than 200 actions in an hour, across all clients. Outpost
  raises an alert, and everyone with `automation:manage` gets a **Workflow
  health** notification.
- Its AI step failed 5 times in an hour in one client. Everyone with
  `automation:manage` gets a **Workflow health** notification.

The workflow shows **Paused** and says why. Find the cause on the **Runs**
tab, fix the workflow, then select **Resume** in its row or at the top of the
workflow.

To change when Outpost pauses a workflow, see
[Change the safety limits](#change-the-safety-limits).

## Change the safety limits

The two safety limits apply to every workflow in your practice.

1. On the **Workflows** page, find **Safety limits** under **Pause all
   workflows**.
2. In **Actions per workflow per hour**, enter 1 to 10,000. The default is
   200. A workflow that goes past it pauses itself and raises an alert.
3. In **Client emails per ticket per day**, enter 0 to 50. The default is 3.
   Further client emails about that ticket that day are skipped. `0` stops all
   workflow email to clients.
4. Select **Save limits**. The page shows **Limits saved.**

**Safety limits** is on the practice view only. The same settings are also
available through the API and the `update_workflow_settings` MCP tool.

## Fix a workflow that needs attention

A turned-on workflow with a problem shows **Needs attention** in the list, and
the workflow lists each problem under **This workflow needs attention**:

| Problem | What to do |
| --- | --- |
| A queue, group, business schedule, or template does not exist in some clients. | Create it with the same name in those clients, or change the scope. The step is skipped there until you do. |
| Nobody holds a role it notifies, or the role no longer exists. | Give someone the role, or pick other recipients. |
| **AI is not available, so its steps take their fallback.** | Set up AI. See [AI steps in workflows](/service-desk/workflow-ai-steps/#before-you-begin). |
| Paused for too many actions, or for AI failures. | See [Resume a paused workflow](#resume-a-paused-workflow). |

When you save a workflow that sets the same field as another enabled workflow
on the same trigger, the console saves it and shows **Saved, but another
workflow changes the same thing**. Whichever runs later wins. Change the
conditions or the run order if that is not what you want.

## Edit an older client rule

1. Open the rule from the **Workflows** page. Its row carries its client's
   name.
2. Change its trigger, conditions, or steps. The builder is in rule mode, so
   it offers only what a rule can do.
3. Select **Save**.

You can test a rule the same way as a workflow. The **Runs** tab is not
available for a rule. To give a rule branches, AI, or more clients, build a
workflow that does the same and delete the rule.

## Verify

- The workflow shows **On** on the **Workflows** page.
- After its trigger fires, the **Runs** tab lists a run, and the ticket's
  conversation shows the workflow's name.

## Next steps

- [AI steps in workflows](/service-desk/workflow-ai-steps/)
- [Workflow reference](/service-desk/workflow-reference/)
- [Notifications](/depot/notifications/)