How to Build Approval Workflows for Marketing Content at Scale

A campaign goes live with a typo in the legal disclaimer. Or a regional team publishes pricing that was never signed off by finance. Or a product claim slips past compliance and now your brand is fielding a regulator's letter. At enterprise scale, the failure mode is rarely the content itself. It is the approval workflow that was supposed to catch the problem and didn't, because it lived in a spreadsheet, a Slack thread, and three people's memory.

This is the quiet tax of marketing at scale. The more brands, markets, and contributors you add, the more the review process strains, until "who approved this?" becomes a question nobody can answer with confidence. Sanity, the Content Operating System for the enterprise, treats approval as a first-class part of the content model rather than a bolt-on afterthought, which is what makes governed review survivable across dozens of teams.

This guide reframes approval workflows as an architecture problem, not a process-document problem. We will cover how to model review states, batch changes safely, prove who did what, and keep velocity high while the number of reviewers climbs. The goal is governance that scales with output instead of throttling it.

Why approval breaks when you add brands and markets

The approval process that works for one brand and one market is almost never the one that survives twelve of each. Early on, review is informal and human. A marketer writes, a manager reads, and someone hits publish. That model has no friction because everyone shares context and the stakes of a mistake are contained. It also has no record, which is fine until the day someone asks for one.

Scale changes the math in three ways. First, the number of review paths multiplies: legal review for one market is not legal review for another, and a claim that is fine in the United States may be illegal in Germany. Second, the people doing the reviewing stop sharing context, so the reviewer no longer knows whether a change is routine or risky. Third, volume turns every manual handoff into a queue, and queues are where deadlines die.

The instinctive fix is to write a longer process document. That rarely works, because a document describes the workflow without enforcing it. The contributor who is in a hurry routes around it, the reviewer who is on vacation becomes a single point of failure, and the audit trail exists only in email. What enterprises actually need is a workflow that is encoded in the system where content lives, so the rules are structural rather than aspirational.

This is the reframe: stop treating approval as a behavior you ask people to follow, and start treating it as a property of the content model. When review state, ownership, and permissions are modeled data, the workflow enforces itself, scales with the number of teams, and produces an audit trail as a side effect rather than a separate chore.

Model review state as data, not as a side conversation

The first architectural decision is where the status of a piece of content lives. In too many organizations, it lives nowhere durable: a draft is "ready" because someone said so in a meeting, and "approved" because a manager nodded. When the status is not data, you cannot query it, report on it, gate publishing on it, or reconstruct it after the fact.

The alternative is to make review state an explicit field in your content model. A document carries a status (draft, in review, approved, scheduled), an owner, an assigned reviewer, and a timestamp for each transition. Because Sanity lets you model your business rather than forcing your business into a fixed template, these fields are part of the schema you define, queryable with GROQ across the entire estate. You can ask, in one query, for every approved-but-unpublished asset in the German market, or every document that has sat in review for more than five days.

That queryability is what turns governance from a hope into a dashboard. A content operations lead can see the real state of the pipeline instead of pinging team leads for status. A compliance officer can pull every document a given reviewer signed off on. The Studio surfaces these states to editors directly, so the person doing the work sees the same truth as the person auditing it.

Modeling state as data also makes automation possible. Once "approved" is a real field with a real transition, Functions can react to it: notify the next reviewer, trigger a translation job, run an automated compliance check, or move the document into a release. The workflow stops depending on someone remembering the next step, because the next step is wired to the state change. That is the difference between a process you document and a process the system runs for you.

Batch changes safely with Content Releases

Most approval pain at scale is not about a single document. It is about coordinating many documents that must go live together and must be reviewed together. A product launch touches the homepage, a dozen landing pages, pricing tables, legal copy, and localized variants across markets. Approving each one in isolation guarantees that something ships half-finished, with the new hero image live above the old pricing.

This is where the traditional CMS model fails enterprises. If your only unit of work is the individual document, then "approve the launch" is not an operation the system understands. Teams improvise with publish windows, frozen environments, and a war room on launch night, all of which are expensive and none of which are auditable.

Content Releases reframe the unit of approval from the document to the batch. A release groups related changes so they can be staged, reviewed, and shipped as a single unit, the editorial equivalent of a git branch that the whole team can see. A reviewer approves the launch, not forty disconnected edits, and the release goes live atomically so the front end never shows a half-applied state. If the launch slips, you reschedule the release instead of unwinding forty manual changes.

For a regulated enterprise this is also a compliance instrument. The release becomes the artifact that legal signed off on, with a clear boundary around exactly what was approved. There is no ambiguity about whether a late edit snuck in after review, because the late edit either belongs to the approved release or it does not. Combined with modeled review state, this gives content-operations leads a clean answer to the question that haunts every audit: what, precisely, was approved, by whom, and when did it go live.

Encode who can do what with Roles, Permissions, and SSO

An approval workflow is only as trustworthy as the permission model underneath it. If any contributor can mark their own work approved, the workflow is theater. Real governance requires that the system enforce separation of duties: the person who writes is not the person who approves, and the person who approves a legal claim has the authority to do so.

Roles & Permissions let you express these constraints structurally. You define who can edit, who can move a document into review, who can approve, and who can publish, scoped to the parts of the content estate that each role is responsible for. A market editor can draft and submit but not approve; a legal reviewer can approve compliance-sensitive document types but not touch design. The workflow you modeled in the previous step is enforced because the transitions it depends on are gated by permission.

SSO ties this to the identity your enterprise already runs, so access follows the same provisioning and deprovisioning as every other corporate system. When someone leaves a team, their approval authority disappears with their directory account, not when an admin remembers to revoke it. For an organization with hundreds of contributors across agencies and markets, that integration is the difference between manageable access and a standing audit finding.

Audit logs close the loop. Every transition, every approval, every publish is recorded, so the audit trail is a byproduct of working rather than a separate reconstruction effort. When a regulator or an internal review asks who approved a given claim, the answer is a query, not a forensic exercise across inboxes. This is what separating modeled workflow from enforced workflow looks like in practice: the rules are not suggestions, they are the system.

Scale across brands and markets with Studio Workspaces

A global enterprise does not run one approval workflow. It runs many, because a luxury brand's review standards are not a value brand's, and a regulated market's sign-off chain is not an unregulated one. The naive solution is to spin up a separate CMS instance per brand, which fragments governance and makes cross-brand reporting impossible. The opposite naive solution, one workflow for everyone, forces every team into the strictest or loosest common denominator.

Studio Workspaces let one Sanity Studio host multiple brands and markets, each with its own configuration, while sharing a foundation. A market that needs a legal-review step gets it; a market that does not, skips it. Editors see only the workspaces they are entitled to, and the content for each brand stays organized rather than tangled. Because the brands share one platform, a content-operations lead can still report across all of them, which a fleet of separate instances would never allow.

This is the pillar that legacy DXPs struggle with most. Multi-brand support in an all-in-one suite usually means a heavyweight, separately licensed deployment per brand, with its own implementation cost and its own upgrade cycle. The shared-foundation model inverts that: you add a brand by adding a workspace, not by standing up another instance.

Localization compounds the benefit. With Translations integrations for Phrase and Smartling plus a native plugin, the approval workflow can include the localization step rather than treating it as a separate system the approved content disappears into. A document can be approved in the source market, dispatched for translation, and routed back through each market's review path, all within one governed environment. That is how you scale output without scaling the headcount that reviews it, because the structure does the routing the people used to do by hand.

Automate the routing so velocity survives governance

The fear every marketing leader has about formal approval is that it slows everything down. It often does, but not because review is inherently slow. It is slow because the handoffs are manual: someone has to notice a document is ready, find the right reviewer, ping them, wait, and chase. Each manual step adds latency and a chance for the work to stall.

The fix is to automate the routing while keeping the judgment human. Functions react to state changes in your content model, so when a document moves to in review, the right reviewer is notified automatically, an automated compliance check can flag obvious problems before a human ever looks, and an approved document can be queued into its release without anyone copying anything by hand. The App SDK lets you build the bespoke review surfaces a specific team needs, rather than bending their process to a generic inbox.

This is also where governed AI belongs in the enterprise picture, framed as risk control rather than novelty. AI can draft, summarize changes for a reviewer, or pre-screen content against a policy, but the approval gate stays human and the audit log records both the AI contribution and the human sign-off. Because Sanity is built for AI rather than bolting it on, the automated steps live inside the same governed workflow as the manual ones, which means an AI-assisted edit is reviewed and recorded exactly like any other.

The outcome is the reframe this whole guide argues for: governance and velocity are not opposites. When the routing is automated and the state is modeled, adding a review step costs you almost no time, because the system does the chasing. You get the audit trail, the separation of duties, and the compliance boundary, and the campaign still ships on schedule. That is governance that scales output instead of throttling it.