Why Workflow Should Be a Layer, Not a Feature, in Enterprise CMSes

Every enterprise team that runs a legacy DXP has lived the same failure: a routine content change stalls for three days because the approval flow is welded into the page-authoring UI, the legal reviewer needs a login to a system they will use twice a year, and a market-specific variant has to fork the entire template to get its own sign-off step. Workflow was shipped as a feature of the authoring tool, so it only works where the authoring tool works. The moment content has to move through a channel, a market, or a system the vendor did not anticipate, governance falls back to spreadsheets and Slack.

That is the core mistake this article argues against: treating workflow as a feature bolted to an editor rather than a layer that spans your entire content operation. Sanity is the Content Operating System for the enterprise, an intelligent backend where governance is a property of the content itself, not of a single screen. When approvals, versioning, and audit live in the data layer, they follow the content across every surface, market, and integration.

We will walk through why the feature model breaks at enterprise scale, what a workflow layer actually looks like, and how to reason about the trade-offs against the DXP you run today.

The failure mode: workflow welded to the authoring UI

Most legacy DXPs model workflow as a state machine attached to a page or an asset inside their authoring interface. It works beautifully in the demo, where one editor moves one page from draft to review to publish. It breaks the moment your operation stops looking like the demo. A localized campaign that spans nine markets needs nine variants, each with its own reviewer, its own legal check, and its own release date. A product update that has to appear on the website, the mobile app, a partner portal, and an in-store screen needs the same approval to be respected by four different delivery systems. When workflow is a feature of the page editor, none of that transfers. The approval you captured on the web page means nothing to the app, because the app never touched the editor.

The symptom every content-operations lead recognizes is the shadow process. The official workflow governs a fraction of what actually ships, and the rest is coordinated in email threads, shared documents, and status meetings. Auditors ask who approved a piece of content and the honest answer is that the record lives in three tools, none of which is the CMS. This is not a training problem or a discipline problem. It is an architecture problem. Governance that is scoped to one screen cannot govern an operation that spans many. The fix is not a better editor. It is moving the workflow down a level, so it attaches to the content rather than the tool that happened to create it. This is the first pillar in practice: model your business, including how content actually moves through it, rather than accepting the vendor's default state machine.

What 'workflow as a layer' actually means

A workflow layer treats state, versioning, and approval as attributes of content in the data store, not behaviors of a UI. The distinction is concrete. In the feature model, a page has a status because the page editor tracks it. In the layer model, every document carries its own governed state in the content backend, and any surface that reads that document, a website, an app, a translation vendor, an analytics pipeline, can see and respect it. Approval stops being a screen you click through and becomes a fact about the content that travels wherever the content travels.

Sanity implements this through the Content Lake, a multi-tenant, multi-region content store where documents are structured, queryable data rather than pages locked to a renderer. Because state lives with the data, you can express workflow as automation over that data. Functions and the App SDK let you attach compliance checks, moderation, translation hand-offs, or AI enrichment to content transitions, so a document moving from review to ready can trigger the exact steps your business requires without a human copying it into another tool. Content Releases let you stage and ship batches of content as a single governed unit, the enterprise equivalent of a branch that editors, not just developers, can reason about. Roles & Permissions, SSO, and Audit logs mean the record of who did what is captured at the layer, once, and applies to everything built on top. This maps to the second pillar, automate everything: the workflow is not a checklist someone remembers to run, it is behavior the platform enforces on the content itself.

Why the layer model survives multi-brand and multi-market scale

The real test of a governance model is what happens when one brand becomes twelve and one market becomes forty. In the feature model, scale means duplication. Each brand gets its own site, each site gets its own copy of the workflow configuration, and keeping those configurations consistent becomes a full-time coordination job. When compliance changes a required review step, someone has to propagate it across every property by hand, and the properties drift because propagation is manual. The governance you designed centrally decays into dozens of slightly different local governances.

A layer collapses that duplication. Sanity Studio Workspaces let a single Studio model multiple brands and markets against a shared content foundation, so the same governance primitives, roles, releases, audit, apply across the estate instead of being re-implemented per property. Content is modeled once and localized rather than forked, which means a legal reviewer's sign-off step is defined at the layer and inherited everywhere it is relevant. Translations flow through native tooling or integrations with Phrase and Smartling, so a market variant is a governed state of one content model, not a separate island with its own private approval history. The operational consequence is that adding the fortieth market is a modeling exercise, not a re-platforming exercise. This is the fifth differentiator made tangible: rigid systems force you to scale people to keep dozens of properties in sync, while a shared foundation lets you scale output instead. Governance defined once, enforced everywhere, is the only version that holds at enterprise scale.

Governance, audit, and compliance when AI enters the loop

Enterprises are now pushing AI-generated and AI-assisted content into the same pipelines that carry human-authored content, and the governance question gets sharper, not softer. If a model drafts a product description, who reviewed it, what source it was grounded in, and when it was approved are not nice-to-haves, they are audit requirements, and under frameworks like the EU AI Act they are increasingly legal ones. When workflow is a feature of the editor, AI content typically enters through a side door, an API write or a bulk import, that skips the review states entirely. The auditability you built for human content simply does not cover the machine content, which is exactly the content regulators will ask about.

A workflow layer closes that gap because it does not care whether a document was written by a person or a process. AI-generated content is written into the Content Lake as a governed document like any other, so it enters the same review states, carries the same Audit logs, and passes through the same Content Releases before it ships. Functions can enforce a mandatory human-in-the-loop step or a grounding check before an AI draft is allowed to advance. This is the difference between legacy platforms that bolt AI on as a separate capability and a Content Operating System that is built for it: the AI is not a special case sitting outside governance, it is content moving through the same enforced layer. Sanity's compliance posture, SOC 2 Type II, GDPR, and regional hosting with a published sub-processor list, applies to that content whether a human or a model produced it. For a risk-and-compliance owner, that single-loop property is the entire argument.

Total cost of ownership: the hidden bill of the feature model

The cost of workflow-as-a-feature does not show up on the license line, which is why it is so often missed in an RFP. It shows up in implementation and in ongoing operations. Because governance is scoped to the authoring tool, every new channel, every acquisition, every market expansion requires re-implementing the workflow inside that tool's constraints, usually through a system integrator engagement measured in quarters. The shadow processes described earlier are a labor cost too: the coordination meetings, the manual propagation of policy changes, the audit-prep scrambles are all people-time that scales with the number of properties.

The layer model changes the cost curve because the expensive part, governance, is built once at the content backend and reused. Adding a channel means pointing a new frontend at the same governed Content Lake, not rebuilding an approval flow. Because Sanity is composable, you integrate the systems you already run through APIs, the App SDK, and Functions rather than replacing them or forcing them into a suite's assumptions, and the Partner network handles large rollouts when internal capacity is the constraint. The classic enterprise argument holds here: the modern composable stack is cheaper to evolve than the legacy DXP because the evolution does not require re-touching governance every time the surface area grows. This is the third pillar, power anything, read through a finance lens. You are not paying to re-implement the same control plane for each new destination. You are paying for it once and spending the saved budget on output. Legacy DXPs earn their keep on deep marketing-suite integration and mature partner ecosystems, but on the cost of change, the layer wins.