Managing playbooks
Creating and editing playbooks in the portal — every field, what it affects, and the limits of the cloud editor.
Playbooks is where triage profiles are created and edited. For guidance on writing a good one, see Anatomy of a playbook; this page covers the mechanics of the editor.
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
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.
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
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. Remember that team scoping governs manual use, not auto-classification.
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.
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.
Revision history. The desktop keeps a local per-playbook revision trail. In the portal, the equivalent record is the Audit log, which captures every create, update and delete with before/after payloads.
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.
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.