# A Content Operations Playbook

> Source: https://agilitycms.com/docs/editors/content-operations-playbook

Content operations is how your team gets content from an idea to your live site, again and again, without surprises. Agility gives you the pieces: roles, Staging, preview, approvals, scheduling, batch publishing, version history and reports. This playbook shows one way to put them together into a working routine. Adapt it to your team's size; the principles stay the same.

## The five parts of a content operation

| Part | The question it answers | Where it lives in Agility |
| --- | --- | --- |
| **Roles** | Who can create, review and publish? | Built-in roles, Custom Roles, Teams |
| **Workflow** | What steps does a change go through? | Staging, preview, approvals, publishing |
| **Cadence** | When does work happen and go live? | Tasks, scheduling, batch publishing |
| **Governance** | What rules keep content consistent and safe? | Content models, permissions, version history |
| **Measurement** | Did it work? | Reports, analytics apps |

## 1. Roles: decide who does what

Start with the jobs, not the people. Most teams need some version of these:

| Job | What they do | A built-in role that fits |
| --- | --- | --- |
| Writer | Creates and edits content, requests approval | **Editor** (or **Contributor** if they should only edit their own items) |
| Reviewer | Checks content and approves or declines it | **Approver** |
| Publisher | Takes approved content live, schedules releases | **Publisher** |
| Content lead | Owns the calendar, the checklists and the reports | **Manager**, or a Custom Role |
| Stakeholder | Reads and comments but never changes content | **Reader** |

A few things worth knowing before you assign roles:

- **Publisher, Approver and Delete are each Editor plus one permission.** None includes the others. Someone who must approve *and* publish needs both roles, a Manager role, or a Custom Role.
- **Give the smallest role that does the job.** It is easier to add a permission later than to undo a mistake made with one.
- **The same rules apply to AI assistants.** An assistant connected to Agility acts as the person using it, with their role. See [Governing AI Access to Agility CMS](/docs/owners-admins/governing-ai-access).

For the full side-by-side view, see [Roles and Permissions Matrix](/docs/owners-admins/roles-and-permissions-matrix). For ready-made setups for agencies, regional teams, freelancers and reviewers, see [Role Design Recipes](/docs/owners-admins/role-design-recipes).

## 2. Workflow: one path from draft to live

Agree on a single path every change follows. Here is a common one:

1. **Draft.** The writer creates or edits the item or page. Saving puts it in **Staging**. If the item was already published, the live version stays as it is until the new version is published.
2. **Preview.** The writer checks the change in your site's design using **Preview**. Preview needs a preview environment that your developer sets up. See [Previewing, Publishing, and Content States](/docs/editors/preview-and-publishing).
3. **Request approval.** On pages and content lists that require approval, the writer requests it. The item waits for a reviewer.
4. **Review.** The reviewer approves it, or declines it with notes so the writer can fix it and request approval again.
5. **Publish or schedule.** A publisher publishes it now, schedules it for later, or adds it to a batch with related changes.

To make approvals part of this path, turn on **Requires Approval** for pages or **Enable Approval Workflow** for content lists. See [Approvals and Workflows](/docs/editors/workflows).

> [!IMPORTANT]
> **Publishing includes nested linked content by default.** When you publish a page or content item, its nested linked content is published with it, including any saved changes in that nested content that nobody has reviewed yet. Shared linked content is not affected. To publish only the item itself, tick **Publish this item only** in the Publish prompt (the option appears only when there is nested content to include). Make "check the nested content too" part of every review.

## 3. Cadence: a weekly rhythm

A predictable rhythm means fewer last-minute publishes. This is an example for a team that publishes several times a week; change the days to suit you.

| When | What happens | Agility features that help |
| --- | --- | --- |
| **Monday: plan** | Agree on what ships this week. Create a task for each piece, with an owner and a due date. | [Task Management](/docs/editors/task-management) |
| **Tuesday to Wednesday: write** | Writers draft and preview. Changes stay in Staging. | Staging, Preview |
| **Thursday: review** | Reviewers work through approval requests. Writers fix anything declined. | [Approvals and Workflows](/docs/editors/workflows) |
| **Thursday to Friday: release** | Publishers schedule time-sensitive items and publish the rest, together where they belong together. | [Scheduling Overview](/docs/editors/scheduling), [Batch Content Publishing](/docs/editors/batch-content-publishing) |
| **Friday: check** | Look at what went live and what is still waiting. | **Recent Changes** and **Ready to Publish** reports |

For longer-range planning (launches, campaigns, seasonal content), see [Plan an Editorial Calendar with Scheduling and Approvals](/docs/editors/plan-an-editorial-calendar).

## 4. Governance: the rules that keep content healthy

Governance is the set of agreements that stop content drifting. Write them down and keep them short.

- **The content model is the style guide's backbone.** Fields decide what every item must contain. When editors keep asking for a field that doesn't exist, or keep pasting the same thing into a rich text field, that is a request to your developers to change the model, not a habit to live with. See [Writing for Structured Content](/docs/editors/writing-for-structured-content).
- **Have a definition of done.** A short checklist every item passes before approval: required fields filled, SEO title and description written, alt text on images, links checked, preview viewed. The [Accessible Content Checklist for Editors](/docs/editors/accessible-content-checklist) is a good start.
- **Use version history as your safety net.** Every saved change is a version you can view, compare and restore. Restoring brings the earlier version back in Staging for you to publish. See [Version History and Commenting](/docs/editors/versioning).
- **Leave context where the work is.** Use comments on items and pages to explain why something changed, and assign tasks rather than sending side messages. Agility can email people when they're mentioned in a comment. See [Manage your notifications](/docs/editors/manage-your-notifications).
- **Decide where AI may help, and how much.** Choose, per kind of content, whether an AI assistant only drafts (a person reviews and publishes), goes through an approver, or publishes on its own after automated checks. See [When to Use AI, and When Not To](/docs/editors/when-to-use-ai).
- **Review access regularly.** People change jobs and agencies finish projects. Check who has which role, for example with the **Access Report** under Reports.

## 5. Measurement: close the loop

Publishing is not the end. Pick a few signals and look at them on a schedule:

- **Throughput:** how much went live, from the **Recent Changes** report.
- **Backlog:** what is approved or saved but not yet live, from the **Ready to Publish** report.
- **Quality:** declined approvals and items that needed a second round, which point at unclear briefs or missing checklist items.
- **Performance:** how readers respond, from your analytics. See [Measure What You Publish](/docs/editors/measure-what-you-publish).

Reports can be exported, which helps when you share them with people who don't work in Agility. See [Accessing Reports](/docs/owners-admins/accessing-reports).

## Common mistakes

1. **Everyone can publish.** If every writer holds Publisher, approvals become optional in practice. Keep Publish with the people accountable for what goes live.
2. **Approving the page but not what's nested in it.** Nested linked content goes live with its parent by default. Review it, or publish the item only.
3. **Editing over someone else's draft.** If an item already has unpublished changes in Staging, your save becomes part of that Staging version. Check first, or use a task or comment to coordinate.
4. **Scheduling an update and forgetting the old version is still live.** A scheduled release replaces the live version at the release time; until then, the current version stays up. If it must come down now, unpublish it first.
5. **Formatting instead of fields.** Bold text standing in for a subtitle, or a pasted table standing in for structured data, can't be reused, filtered or checked. Ask for a field.
6. **Measuring nothing.** Without a weekly look at what went live and how it performed, the routine never improves.

## Related articles

- [Roles and Permissions Matrix](/docs/owners-admins/roles-and-permissions-matrix)
- [Approvals and Workflows](/docs/editors/workflows)
- [Plan an Editorial Calendar with Scheduling and Approvals](/docs/editors/plan-an-editorial-calendar)
- [Writing for Structured Content](/docs/editors/writing-for-structured-content)
- [Measure What You Publish](/docs/editors/measure-what-you-publish)
- [Work Faster in Agility](/docs/editors/work-faster-in-agility)