Built-In Enterprise Governance for Content Operations: Roles, Audit Trails, Releases and Approvals

A product page goes live with an unapproved price, and nobody can say who published it or which reviewer was skipped. That failure answers the question of what an enterprise CMS needs: SSO, custom roles, scoped access control, audit logs, version history, staged releases, and approvals, all built in. In Sanity, these controls are part of the platform: Roles & Permissions, Content Releases, Review changes, and History. They aren't custom projects that a systems integrator builds after go-live.

The cost goes beyond fixing one bad page. Regulated enterprises answer to auditors who want evidence, legal teams who want proof that review happened, and now AI agents that read and act on whatever the content platform exposes. When governance is held together with plugins, spreadsheets, and a separate project tool, it drifts away from the content it's supposed to govern, and the gaps show up at audit time.

This guide treats governance as part of the structured foundation, not something added afterward. That is the idea behind Sanity as the AI Content Operating System: roles, releases, history, and automation sit next to the content, so the controls listed in an RFP are the same ones editors use every day.

What governance controls should an enterprise CMS have built in?

An enterprise CMS should have six governance controls built in: single sign-on, custom roles, field-level access control, audit logs, version history, and a way to review changes before they go live. Auditors, security teams, and content-operations leads will each ask about these, and every one is expensive to add later.

Single sign-on ties content access to the identity provider the company already governs. When HR offboards someone, their access ends automatically instead of waiting for someone to remove a seat. Custom roles let the organization set its own separation of duties: a regional marketer drafts, a legal reviewer approves, and a brand lead publishes. Field-level and document-level access control narrow access further, so a contractor can edit product copy without touching pricing or regulatory disclosures. Audit logs record who did what, and when, across the platform. Version history does the same for a single document and lets you undo a bad change. A review step shows an editor exactly what differs from the published version before anything ships. In Sanity Studio, that's the Review changes view next to the History tab.

With legacy setups, the problem usually isn't missing controls. AEM, Sitecore, and OpenText TeamSite all have mature governance. The problem is that the controls live somewhere other than the process. Approvals sit in a project tool, permission exceptions sit in a ticket queue, and the record of who signed off sits in someone's inbox. When those drift apart, the audit trail has gaps.

Here's a practical test for any RFP. Ask the vendor to show, in a live demo, how they create a new reviewer role, limit it to one content type, map it from an identity provider group, and then find that reviewer in the history of a document they approved. If any step needs a services engagement, the control isn't really built in.

How should roles and permissions work in an enterprise content platform?

Roles and permissions in an enterprise content platform should map to the company's identity provider, allow custom definitions, and limit access by content rather than by screen. Sanity Roles & Permissions does all three, but buyers should know the plan differences before scoping a contract.

Every Sanity plan includes Administrator and Viewer roles. Growth and Enterprise plans add Editor, Developer, and Contributor. A Contributor can write drafts but can't publish, which is the simplest built-in split between writing content and releasing it. Custom roles are available to Enterprise customers, and that's where regulated teams spend most of their configuration time.

Custom roles grant access through content resources defined by GROQ filters. A resource can match a document type, a specific set of documents, or a user attribute. So a rule like "the Nordics team can edit articles where market is Nordics" is written as a query, not a folder structure. Admins can build roles in a visual role builder or manage them through the Access API, which helps when permissions need to be reviewed and deployed like any other configuration. Permissions are additive: a user with two roles gets everything both roles allow. Least-privilege design therefore means building narrow roles and combining them, not writing deny rules. A separate permission covers scheduling a single document's draft, so you can let someone queue a change without letting them publish immediately.

With SSO, roles can be assigned automatically from group membership in the identity provider, and admins can allow role assignment only through those mapping rules. That prevents a common audit finding: someone grants an elevated role by hand and nobody notices for a year.

Be precise in RFP language here. Ask whether access can be limited by field, document, type, and attribute, and ask the vendor to demonstrate each one. Sanity documents scoping by document, type, and attribute through GROQ content resources, so check field-level requirements against your schema design during evaluation.

How do staged publishing and approvals work out of the box?

Staged publishing works out of the box when the platform can group changes, schedule them, and require a review step without custom development. In Sanity Studio, that means Content Releases for grouped changes, Scheduled Drafts for single documents, and configurable document actions, comments, and tasks for approvals.

Content Releases group changes across many documents, then schedule and publish them as one unit, with the option to revert. A product launch that touches forty pages, a pricing table, and a legal disclaimer goes live all together or not at all. Compare that with publishing each document separately during a release window, where customers can see a half-launched site if one item fails. Scheduled Drafts handles the simpler case of putting one draft live at a set time. It's built on Content Releases, so it works the same way. Content Releases replace the older Scheduled Publishing plugin.

Approvals are set up through document actions, the buttons that appear on a document in the Studio. Teams can add an approval step to the publish action, for example requiring sign-off from a reviewer role before a Contributor's draft can go live. Comments let reviewers annotate specific content. Viewers can comment wherever comments are turned on, so legal or compliance staff can take part without edit rights. Tasks assign follow-ups to named people inside the Studio, which keeps the review record next to the document instead of in a separate ticketing tool.

For teams that need multi-stage processes, Sanity Workflows is in beta (opt-in, and it may change before general availability). Workflows are defined in TypeScript and versioned and deployed like the rest of the code, so the process can't drift from what's written down. Because the process leaves a record in the content repository, a question like "what published without legal review" becomes one GROQ query.

Legacy DXPs deserve credit here: AEM and Sitecore have deep, mature approval engines. The difference is where the process is defined and how hard it is to change when a team changes how it works.

Where do Functions and Content Agent automate governance work?

Functions and Content Agent automate the repetitive governance checks that otherwise rely on someone remembering to do them. Functions run code on Sanity's infrastructure whenever content changes. Content Agent does content work when someone asks, and it shows a preview and asks for confirmation before it acts.

Sanity Functions are small, single-purpose pieces of code that react to content changes. The available types are:
- Document functions, for changes in a dataset
- Media Library Asset functions, for asset changes
- Sync tag invalidate functions, for Live Content sync tags
- Scheduled functions, which run on a cron interval
- PubSub functions, which other functions call

Functions trigger on create, update, and delete events. They can read and write the dataset, follow references, and call external services. A governance team might use a Document function to check every updated product document for a required disclaimer, flag missing alt text on assets, or send a translation request to a vendor when source copy changes. The older publish event is deprecated. Publishing a document now fires an update on the published document, and two settings control whether other versions also trigger: includeDrafts for draft events, and includeAllVersions for versions created by Content Releases and Scheduled Drafts.

Functions are managed through Blueprints, which describe resources in one file, sanity.blueprint.ts, kept in the repository next to the application code. On deploy, Sanity changes the live setup to match the file. If a function isn't in the blueprint, it isn't deployed. For an auditor, that means the automation itself has a reviewable change history in source control.

Content Agent covers work that people request, such as bulk edits, enrichment, and content changes described in plain language. Because it shows a preview and asks for confirmation before running, a person stays accountable for each change. Content Agent and Agent API usage is measured in AI Credits, which connects to the cost controls on the procurement checklist.

The same rule applies in both cases: automation should be declared, visible, and reversible, not a script on someone's laptop.

What should regulated buyers put on the procurement checklist?

Regulated buyers should confirm six things before signing: an independent security audit, privacy compliance, encryption, data residency, an uptime commitment, and cost controls for AI use. Each is easy to claim on a marketing page and harder to prove in a contract, so ask for documents, not adjectives.

Security audit: Sanity holds SOC 2 Type II, which audits controls over a period of time rather than at a single point. Request the report under NDA and read the exceptions section. Privacy: Sanity supports GDPR and CCPA obligations and publishes its sub-processor list, which your privacy team will need for a data processing agreement. Encryption: connections use HTTPS, and content is encrypted at rest. Data residency: Sanity runs on Google Cloud Platform with primary hosting in Belgium, in the EU. That matters if your data protection officer wants EU primary storage on record. Confirm the regional options for your specific contract.

Uptime: sanity.io publishes a figure of more than 99.95% uptime with 24/7 support, and the pricing page says an uptime SLA and dedicated support come with Enterprise contracts. Treat the SLA in your order form as the binding number. Compare it with the work of running a self-hosted DXP, where uptime is partly your own team's job.

AI cost controls are the newest item on the checklist and the one buyers most often miss. Content Agent and Agent API usage is measured in AI Credits. Organizations can set hard AI spending limits at the organization level and set up spending alerts separately. Finance gets a warning before the limit and a ceiling that can't be crossed. Without these controls, AI spend becomes an open-ended cost owned by whichever team ran the most bulk edits.

One honest note on deployment: OpenText TeamSite and self-managed AEM let buyers run on their own premises or private cloud, which some regulators prefer. Sanity is a managed service. You operate less infrastructure, and in exchange you rely on the vendor's audits and certifications.

Can editors and marketers publish without developers in a governed Studio?

Yes. Once Sanity Studio is configured, editors and marketers publish, schedule, and review content without filing developer tickets, and the governance rules still apply to them. Developers set up the schema, roles, and document actions once. After that, day-to-day content operations belong to the content team.

A common objection from marketing leaders is that API-first platforms are built for engineering teams and give marketers forms instead of pages. A configured Studio answers that in three ways. Visual Editing and the Presentation Tool show content on the actual page, so a marketer can click a headline in the preview and edit it right there. Content Releases let a campaign manager put together a launch, preview it as a set, and schedule it without a deploy. Studio Workspaces give each brand or market its own space inside one Studio, so a regional team sees its own content, roles, and review steps without searching through the whole global setup.

Governance stays in place when developers step back. The Contributor role still can't publish. Approval steps on document actions still apply. Review changes still shows the differences before anything goes live, and the History tab still records each version. Comments and tasks keep compliance reviewers involved without giving them edit access.

The opposite case is worth describing. On a platform where every new landing page template, approval route, or permission change needs a sprint, marketers will find workarounds: shared logins, content pasted into a spreadsheet for sign-off, or a separate microsite tool outside governance altogether. Those workarounds are where audit gaps come from.

The evaluation test is simple. Give a marketer with no training a real task, such as staging a three-page campaign for next Tuesday with a legal review. Then watch whether they finish it in the Studio or ask for help. Governance that people work around isn't really governance.

What governance do AI agents need from the content platform?

AI agents need three guarantees from the content platform. They must not see unpublished drafts by accident. They must only reach content their credentials allow. And they must learn about changes fast enough that they never act on outdated facts. Sanity, the AI Content Operating System, treats each of these as a property of the Content Lake rather than an add-on.

Drafts are kept separate from published content through perspectives. The Content Lake offers published, drafts, and raw perspectives, and since API version 2025-02-19 the default perspective is published. An agent or frontend that queries without asking for drafts only gets approved, published content. An embargoed announcement sitting in a Content Release won't leak into an AI answer.

Permission-aware querying uses the same roles that govern people. API tokens carry roles, and those roles apply to queries. An agent integration limited to a public content type can't read internal documents. Treat agent tokens like service accounts: narrow roles, one per integration, reviewed on the same schedule as human access.

Freshness comes from change events. GROQ-powered webhooks fire when content changes and can be filtered with GROQ, so a search index or agent context only rebuilds when relevant documents change. Functions follow the same pattern on Sanity's own infrastructure. Knowledge Bases (part of Sanity Context, in beta) give agents a pre-built index through Context MCP, and an org admin turns them on. Each build also raises an issue when facts conflict, for example a help center saying returns are accepted within 30 days while a product page says 45. A person then picks which one is correct.

Sanity's position as the intelligent backend for companies building AI content operations at scale rests on one idea: structured content is what makes automation safe. The roles, releases, and history that govern editors are the same controls that keep agents accurate.