# Managing playbooks

> Creating and editing playbooks in the portal. Every field, what it affects, and the limits of the cloud editor.

Source: https://triagic.com/docs/admin/playbooks

**Playbooks** is where triage profiles are created and edited. For guidance on
*writing* a good one, see [Anatomy of a playbook](/docs/playbooks); this page covers
the mechanics of the editor.

## The form [#the-form]

| Field                   | Required          | What it does                                                                                                                        |
| ----------------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| **Name**                | Yes, max 80 chars | Identifies the playbook everywhere. Must be unique; a duplicate is rejected with *"A playbook with this name already exists."* |
| **Description**         | Recommended       | Fed to the classifier. This is the primary signal for which tickets get routed here.                                                |
| **Routing hints**       | Optional          | Also fed to the classifier: keywords, merchant names, example subjects.                                                             |
| **Triage instructions** | **Yes**           | Appended to the investigator's system prompt for every ticket on this playbook, and for its follow-up chats.                        |
| **Data sources**        | Optional          | The MCP servers the agent may call. **None selected means all.**                                                               |
| **Visibility**          | Yes               | Everyone in the organization, or only selected teams.                                                                               |

### Data sources [#data-sources]

The picker shows one pill per shared integration key, with its last reported tool
count. Selecting none is not "no tools". It means no restriction.

A key that a playbook references but which no longer exists renders as a dashed,
dimmed pill labelled *"no longer available"*. It stays visible so you can toggle it
off deliberately, instead of vanishing and silently changing the playbook's scope on
your next save.

> **Note:** Local tools are always available
>
> Similar-ticket search and the other built-in tools are not part of the allowlist and
> are never scoped away.

### Visibility [#visibility]

**Everyone in the organization** is the default and the right answer most of the time.

**Only selected teams** reveals a team picker. You need at least one team to exist
first. See [Teams](/docs/admin/teams). Remember that team scoping governs manual use,
not auto-classification.

## Enabling and disabling [#enabling-and-disabling]

A playbook can be disabled without deleting it. A disabled playbook:

* is skipped by auto-classification
* cannot be manually assigned to a ticket
* keeps its name on tickets that already reference it, for history

Tickets still assigned to a disabled playbook fall back to **generic triage**: the
standard prompt, all tools. Its instructions and its data-source scoping no longer
apply even though its name still shows on the ticket. That is worth knowing before you
disable a playbook that a lot of open tickets point at.

Deleting a playbook that tickets or generated reports reference disables it instead of
deleting it, for the same reason.

## Generate a playbook from a prompt [#generate-a-playbook-from-a-prompt]

Admins can have Triagic draft a playbook instead of writing it from scratch. This
happens in the desktop app, not the portal: on the **Playbooks** page, press
**Generate from a prompt** and describe the kind of ticket, for example *"Driver
payout disputes"*. Under **Make**, pick:

* **Playbook**: name, description, routing hints, triage instructions and the data
  sources it may use.
* **Both, linked**: a [knowledge doc](/docs/admin/knowledge#generate-a-doc-from-a-prompt)
  and a playbook together. The playbook's first step reads the doc, so the agent
  reads the policy and then follows the steps. Needs a cloud-managed install.

Under **It may read**, choose which data sources, whether Triagic tickets (titles,
resolutions and agent notes) and whether existing knowledge docs the AI may look at.
The result is a draft that lives on your desktop and is private to you until you
publish it. The draft shows every field and the data sources the playbook may use.
An empty data source list means the agent may use every source at triage time, as in
the editor above.

**Revising.** Type into **Ask for changes** and press **Revise**. Each changed field
comes back as a redline that you keep or discard on its own, and every change needs
a decision before you can publish. **Edit by hand** saves your own text as a new
version at no cost. To revise a playbook that already exists, press **Revise with a
prompt** (the sparkle icon) on its row in the desktop **Playbooks** list.

**Publishing** is free. **Publish to org** saves the playbook as if you had saved it
in this editor: it gets a new configuration revision, is recorded in
[Audit](/docs/admin/audit) and reaches other desktops on their next sync. A new
playbook is visible to the whole organization; a playbook you revised keeps the
visibility it had. Unless the playbook is private, a data source that isn't shared
with the organization is left out of the published playbook, and the draft page names
it. If every data source the draft picked is one of those, publishing is refused until
you share one with the organization or remove them. On an install that isn't centrally
managed, the playbook is saved on that desktop only.

Generating and revising spend AI through the provider your desktop uses, and each
button shows its price first. See [Spending and budget](/docs/admin/spending#per-run-cap-for-generation).

## What the portal editor does not have [#what-the-portal-editor-does-not-have]

Two things live on the desktop, deliberately:

**Report schedules.** A playbook can run on a cadence and post to the Console. That is
configured in the desktop app. See
[Playbooks in the app](/docs/desktop/playbooks-in-app#report-schedules).

**Revision history.** The desktop keeps a local per-playbook revision trail. In the
portal, the equivalent record is the [Audit log](/docs/admin/audit), which captures
every create, update and delete with before/after payloads.

## After you save [#after-you-save]

The change is stamped with a new configuration revision and reaches connected desktops
on their next sync, within about 15 minutes, or immediately on a manual refresh.

> **Warning:** Existing tickets do not re-route themselves
>
> Classification runs at ingest or on an explicit **Re-investigate**. A ticket already in
> the inbox will not pick up a playbook you just created. Re-investigate it if you want
> the new routing applied.