# Playbooks in the app

> What members see, what admins can edit locally, and where report schedules live.

Source: https://triagic.com/docs/desktop/playbooks-in-app

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](/docs/admin/playbooks). |
| 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 [#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 [#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 [#how-runs-behave]

* Each run lands on the [Reports](/docs/desktop/reports) page as a new edition, and
  anyone who can see the playbook can read it and ask follow-up questions under it.
* Runs use the organization's system identity and the configured LLM credentials,
  never an individual's key. That includes **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_report` task, and are stopped by the monthly spend cap like any other run.

## Revision history [#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](/docs/admin/audit).