Playbooks in the app
What members see, what admins can edit locally, and where report schedules live.
The desktop Playbooks page shows the triage profiles available to you. Whether it is editable depends on how your install is set up.
| Install | Playbooks page |
|---|---|
| Admin, before the first config sync | Fully editable in the app |
| Admin, centrally managed | Read-only. Edit in the web portal. |
| Member, any install | Read-only view of what is shared with you |
A managed install refuses a local write outright rather than accepting it and losing it on the next sync. If you see that refusal, the portal is where the change belongs.
What a member can see
Playbooks are visible either organization-wide or only to selected teams. Team scoping governs who can use a playbook — selecting it in the Console, assigning it to a ticket manually.
Auto-classification is not scoped: every enabled playbook in the organization is considered when a ticket is classified, regardless of team visibility. A ticket can therefore land on a playbook you cannot select by hand. That is intentional — routing should not depend on who happens to be looking.
Report schedules
Scheduled reports are configured here, on the desktop, not in the portal.
A schedule is a preset rather than a cron expression:
- daily
- every weekday
- weekly, on a chosen day
- monthly, on a chosen date (1–28, so no month skips it)
...at a time of day read in a named IANA timezone, so a daylight-saving shift does not move a 09:00 report to 08:00.
An optional brief says what the report should cover. Left blank, it asks for a 24-hour health report on the systems that playbook is scoped to.
How runs behave
- The report body is the first answer in a new Console thread, so anyone who can see the playbook can ask follow-ups in the same conversation.
- Runs use the organization's system identity and the configured LLM credentials — never an individual's key — including for Run now, so an on-demand run is a true preview of the scheduled one.
- A schedule's cursor advances before its report runs, and the next occurrence is computed from the current time. A server that was offline for a week produces one report on the next boot, not a week of backlog.
- A report interrupted by a restart is marked failed rather than left running.
- Report runs are billed to the organization, appear in Usage under the
playbook_reporttask, and are stopped by the monthly spend cap like any other run.
Revision history
The desktop keeps a local revision trail for playbooks — every create, update, disable and delete — visible from the edit dialog. The portal's equivalent record is the Audit log.