Building Content Approval Workflows in Sitecore AI

Content governance is easy to ignore until it bites you: a wrong product name in a hero banner, a half-finished landing page going live, a legally-reviewed disclaimer quietly overwritten. Workflows exist to prevent these moments, and Sitecore AI gives you the tools to enforce a clear path from draft to published.

A workflow is a series of states that reflect how content gets made — typically creation, review, and approval. Sitecore’s Workflows and the Workbox docs cover the fundamentals. What follows is a pattern that works well for small-to-medium teams. Larger teams will need extra steps, which we’ll touch on at the end.

Pages vs. Datasources

The first decision is whether to apply workflow to Page items only, or to both Pages and Datasource items. Page-only is simpler, but it leaves a gap: editors can change a component’s content without the page transitioning state, so changes can slip past review. Covering both closes that gap, but you’ll need a second, lightweight Draft → Approved workflow for datasources — you don’t want validation and notification emails firing on every component edit.

Admin vs User accounts

Worth remembering: administrators are effectively exempt from workflows. They can move items through any state and overwrite content regardless of where it sits. Drafts don’t get auto created.

So for that reason I actually recommend considering that users on the content team might need TWO SitecoreAI accounts! Their User account for day to day editing, and an Admin account which lets them do power-user tasks as required.

A simple but effective setup

Page Workflow — assigned to all Page items across all sites.

• Draft (initial): Submit → Awaiting Approval
• Awaiting Approval: Approve → datasource workflow action → Approved. Reject → Draft.
• Approved (final): triggers Auto Publish if enabled.

Datasource Workflow — assigned to all Datasource items across all sites.

• Draft (initial)
• Approved (final)

A note: don’t enable the Validation step as it can be a severe friction point, and workflow in general doesn’t need more friction.

Note about the Datasource Workflow item references

When editing a Page, the datasource workflow logic is that it will scan direct item references only. It will not dig for further references at the next level deep. For example, if a datasource has a Multi List field, the items referenced by the Multi List field will not move automatically through the workflow on approval.

Scaling Up: Workflows for Large Teams

Once you move past a handful of editors, the simple flow strains. Enterprise marketing teams, regulated industries, and global brands typically need multiple reviewers and work routed to specific people rather than a shared queue.

A large-team workflow might look something like Draft → Editorial Review → Brand/Legal Review → Approved, with distinct rejection paths between states — Legal might bounce back to Editorial rather than all the way to Draft. Role-based assignment is the other key piece: regional approvers for regional content, brand approvers for corporate identity, legal approvers for regulated claims. Map your editorial org chart to your content tree before you build.

Other Use Cases

A few adjacent scenarios use the same primitives. Scheduled campaign content benefits from a “Ready for Launch” state that holds approved pages until a publish date. Multilingual sites often run a parallel translation workflow per language, kicked off when the source page is approved. Compliance-sensitive content in finance, healthcare, or pharma may need an audit trail layered on top, capturing reviewer and timestamp data for regulators.

Where to Go From Here

Start simple. A working Draft → Awaiting Approval → Approved flow that everyone actually uses is worth far more than an elaborate one editors route around. Build the minimum, watch where it breaks down, and add states only when you have evidence they’re needed.