> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zudo.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Playbooks

> Automate what happens when an account matches a trigger — create tasks, raise flags, move accounts between segments, with branches and waits in between.

A playbook watches for accounts matching a trigger and then does something about them: creates a task, raises a flag, moves an account between segments. Between those steps it can branch on a condition or wait.

Find them under **Playbooks** in the sidebar.

<Warning>
  A playbook acts on real accounts. New playbooks are always created switched **off**, and preview lets you see who
  would be enrolled before you switch one on.
</Warning>

## The trigger

A playbook's trigger is the same rule builder [segments](/accounts/segments) use, so everything a segment can match on, a trigger can match on too.

It also carries the same **counting** choice:

| Counting      | Enrols                                                                                         |
| ------------- | ---------------------------------------------------------------------------------------------- |
| **Customers** | One row per customer: [parent accounts](/accounts/parent-accounts), plus accounts in no parent |
| **Accounts**  | Every account, with parent accounts left out                                                   |

Customers is the default, and it matters more here than on a list. Counting accounts on a customer with three accounts means the playbook runs three times and creates three tasks for one customer.

**Preview matches** shows how many accounts a trigger catches and names the first twenty. Worth using before switching anything on — a trigger that quietly matches your whole book is much easier to spot in a list of names than in a number.

## Steps

The flow runs top to bottom. Use the **+** between any two steps to add another.

### Actions

| Action                | What it does                                                                      |
| --------------------- | --------------------------------------------------------------------------------- |
| Create a task         | A task on the account, assigned if you choose                                     |
| Raise a flag          | A risk or opportunity [flag](/accounts/flags), attributed to the playbook         |
| Add to a segment      | Puts the account in a segment, even if the conditions don't match it              |
| Remove from a segment | Holds the account out, and it stays out                                           |
| Update a trait        | Writes a value onto the account — a fixed value, or one worked out from a formula |

**Update a trait** takes either a literal ("Live", today's date) or a formula in the same language smart traits use, with the same `traits.` and `indicators.` names. So a step can work out a next renewal date from the current one rather than only stamping something fixed.

A formula that can't be worked out on a particular account — usually a misspelled trait name — fails that step for that account and the run carries on. It won't write a broken value.

### Rules

**Split into branches** sends a run down one of several paths. Branches are checked left to right and the first match wins, so they read as "if this, else if that". Anything matching none of them takes the **Otherwise** path.

**Wait for a period of time** holds a run for a number of days. It waits the full period whatever else changes meanwhile.

**Wait until rules are met** holds a run until the account matches a condition — someone completes onboarding, usage crosses a line. Give it a maximum, or a run waiting for something that never happens will sit there forever and never reach the steps after it.

## Counters

Every step shows what happened on it: how many runs completed it, failed on it, or are waiting on it.

These are worth reading. A playbook where every run piles up on one wait step looks perfectly healthy as a diagram — the counters are the only thing that tells you the steps below it have barely run.

## When a run ends

A run ends when it reaches the bottom of the flow.

If an account stops matching the trigger part-way through, what happens depends on the playbook's exit setting:

* **Let it finish** (the default) — the run carries on to the end. This matters when a later step writes the very thing the trigger reads, which would otherwise stop the run before it gets there.
* **Stop immediately** — the run halts where it stands, and its remaining steps never happen.

## Run limits

By default an account can go through a playbook again whenever it matches again, once its previous run has ended. You can cap that at a number of runs, or a number of runs in a period.

An account already part-way through a playbook is never enrolled a second time.

## Editing a live playbook

Changing a playbook that has runs in flight lets those runs finish on the flow they started with. They won't restart, and they won't replay steps an account has already had.

## What's not here yet

Sending email and posting to Slack are not available as actions yet. Playbooks currently trigger on accounts only.