Content governance at scale: roles, approvals, and audit for large editorial teams

The question that changes at twenty editors is not whether somebody will publish something wrong. Somebody will. The question is whether you can answer, afterward, who was able to.

With one editor, governance is a conversation. With twenty editors working across ten brands, governance is a system, and the absence of a system shows up in a specific way. Access gets granted by trust rather than by rule. Nobody remembers who has what. The only person who can confidently say who is able to publish to the flagship brand is the person who set it up eighteen months ago, and they have since changed teams.

Here is a practical model. Four questions, in order.

1. Who can get in?

2. What can they touch once they are in?

3. Where does the approval chain live?

4. What happened, and can it be undone?

Most teams answer part of question two and leave the other three until an incident forces the issue.

Question 1: who can get in

Without single sign-on, every person on your content team holds a credential your IT organization cannot see. A password, or a Google account, or a GitHub account. That is a second roster running alongside your real one, and it drifts from the day it is created. People leave, and the row in your CMS stays.

SAML single sign-on moves that decision back into your identity provider, where the rest of your policy already lives. MFA, session rules, and offboarding happen once, in one place. Cosmic supports SAML 2.0 through Okta, Microsoft Entra ID, Google Workspace, or any SAML 2.0 provider, and it is included on Large Workspace and Enterprise plans rather than sold as an add-on.

The operational details are worth knowing before you turn it on, because a few of them surprise people:

• Enabling SSO locks out password and social login for members. Once it is on, password, Google, GitHub, and forgot-password stop working for the team. Tell people before you flip the switch, not after.

• The lock starts as soon as you enable it, even while the connection is still pending. Finish the identity provider setup before the team needs to sign in again.

• There is a breakglass path. The workspace creator and the admin who enabled SSO can still use password login if the identity provider is down.

• A first-time SSO login lands as a Workspace User. If somebody should arrive as an Admin or Manager, invite them before their first sign-in.

One gap matters for governance specifically. SCIM directory sync is not included yet, so roster changes in your identity provider do not flow through automatically. Offboarding is therefore two steps, and doing only one of them leaves a hole. Revoke the person at the identity provider so they cannot complete a new sign-in, then remove them from Workspace > Team. An IdP-only revoke leaves the Cosmic team row in place. A Cosmic-only removal lets their next SSO login quietly add them back as a Workspace User.

Put that two-step in your offboarding checklist as two lines rather than one. Full detail is in SAML SSO: sign in through your identity provider and the single sign-on documentation.

Question 2: what can they touch

Permissions in Cosmic have two layers that you set at the same time: the project layer, which decides which properties somebody reaches, and the bucket layer, which decides what they can do once inside one.

Project roles are Admin, Manager, and User.

• Admin gets everything a Manager can do, plus project usage, settings, and billing.

• Manager has access to all buckets, can add buckets, and can manage members, without seeing the invoice. This is the right role for the person running the content operation.

• User has access to specific buckets only and cannot create new ones.

The important thing about that list is easy to miss: User is the only project role that lets you scope access at all. Admin and Manager both see everything. Teams routinely hand out Manager because it avoids a follow-up request, and in doing so they give a person access to every property in the project.

Bucket roles are where the real editorial decisions live, and there are four.

• Admin: Developer access plus bucket settings and destructive actions.

• Developer: Editor access plus object types, developer tools, and webhooks.

• Editor: add, edit, and delete all content in the bucket.

• Contributor: add and edit their own content, save as draft, limited to the object types you choose.

The line that matters most is Editor versus Developer. An Editor works with content. A Developer changes the shape of content by editing object types and metafields. A freelance writer does not need the ability to delete a metafield, and Developer access hands it to them.

Contributor is the tightest role available and the most underused. You pick exactly which object types the person can touch, and they can only edit content they created themselves. For guest authors, agency writers, and anyone in their first month, this is the correct starting point.

Question 3: the approval chain is a permission, not a document

Most teams write their approval process into a document that new editors read once. The version that actually holds is the one enforced by the software.

Two switches do most of the work, and both are easy to miss in the invite drawer:

• Under Additional permissions for a Developer or Editor there is a Settings checkbox that grants bucket settings and destructive actions. Leave it off unless there is a specific reason to turn it on.

• Under Publishing restrictions for an Editor there is Save content to Draft status only. This gives somebody complete editing ability while keeping the publish decision on your side.

That second one is the whole approval chain for most multi-brand teams. An agency does the work, your team decides when it goes live, and nobody has to remember a policy. It is also the setting that makes it safe to widen editing access, which usually speeds the operation up rather than slowing it down.

One default that works for most teams at this size: content people get Editor on the buckets they work in, developers get Developer, external contributors get Contributor, or Editor with draft-only if they need broader editing, and Admin stays with the one or two people who handle billing.

The API keys are part of this picture too. A read key and a write key are different governance surfaces, and the number of places holding a write key should stay small and deliberate.

import { createBucketClient } from '@cosmicjs/sdk';

// Read-only client. Safe anywhere content is rendered.
const readClient = createBucketClient({
  bucketSlug: 'brand-a',
  readKey: process.env.BRAND_A_READ_KEY!,
});

// Write client. Keep the write key server-side, and out of any
// integration or agent context that does not need to publish.
const writeClient = createBucketClient({
  bucketSlug: 'brand-a',
  readKey: process.env.BRAND_A_READ_KEY!,
  writeKey: process.env.BRAND_A_WRITE_KEY!,
});

Question 4: what happened, and can you undo it

These are two different capabilities and teams often assume one covers the other.

An audit log tells you what happened: sign-ins, role changes, key rotations, billing changes, publishes. It is how you answer the question after an incident. Cosmic includes an audit log on every plan, with the retention window set by plan. Details are in Audit Log: see who did what in your project or workspace.

Revision history is what lets you put the content back. The distinction becomes expensive at scale: an audit log can tell you exactly which twelve objects were damaged and give you no way to reverse it, while revisions let you roll each one back.

At twenty editors across ten brands you want both, and you want somebody to have exercised the rollback once, deliberately, before you need it under pressure.

The rule that keeps this from decaying

Start everybody at the narrowest role that covers today's work, and widen when they ask.

The reason is practical rather than philosophical. Granting more access takes ten seconds and nobody objects. Taking access away is a conversation about trust, even when it is really about tidiness. Over-granting on day one is a decision you are unlikely to revisit, which is exactly why it compounds across ten properties.

Pair that with a quarterly access review. Pull the team list for every property, and for each person ask whether the role still matches what they do. Fifteen minutes per property, four times a year, catches almost everything that would otherwise surface during an audit.

Seat math, and the part most teams get wrong

Two things about seats change how you plan a rollout.

Pending invites count against your seats from the moment you send them. Invite five people, have three accept, and you are still paying for five until you clear the stale invitations. Check Usage > Team members > Seats in use before and after a rollout. Seat allowances come with your plan, and additional seats are $29 per user per month.

AI agents do not consume a human seat. They are counted separately as Team agents, with their own allowance on the same Usage page, and only active agents count, so pausing one frees the slot.

That second fact should change your staffing conversation. When a recurring task comes up, the question is no longer only who to hire. Research, drafting, translation, and content audits are jobs an agent does well without taking a seat a human editor could have used. Judgment calls, approvals, and relationships need a person. Governance applies to agents exactly as it applies to people: give each one the narrowest key that does its job.

Rolling this out across ten properties

Three things save time when you do this at scale rather than one person at a time.

1. Use CSV import. Both the project Team page and the workspace team page have Import team CSV. The columns are first_name, last_name, email, and role, where role is admin, manager, or user. There is a review step before anything sends, and it warns you if the import pushes you past your seat count.

2. Expect false bug reports. Several sidebar sections are admin-only and simply do not appear for other roles: Agents, Workflows, Code, Insights, Billing, Usage, and Settings. Somebody will report a missing feature that is actually a permission working correctly.

3. Know where membership lives. On projects owned by a workspace, the project Team page is hidden, because membership is managed one level up at the workspace. The same three role names apply there, across projects rather than buckets.

The goal of all of this is the thing one of our customers described better than we can:

"Cosmic is: us never having to ask a developer to change anything on the backend of our website."

Maximilian Wuhr, Co-Founder at FINN

Good governance is what makes that safe at ten brands instead of one. Editors publish. Developers build. The permission model is what keeps those two sentences true as the team grows.

Where this fits

A governance model is much easier to run when your properties are administratively together and content-wise separate. That is the structure Cosmic Workspaces are built for: one Workspace, one Project per property, each with its own content, models, keys, and permissions, under one bill and one team.

Large Workspace covers 10 Projects, 30 Buckets, and 30 team members at $2,999/month, and includes SAML SSO. Small Workspace covers 5 Projects, 10 Buckets, and 10 team members at $999/month. Both include a 30-day free trial.

• See the structure: cosmicjs.com/workspaces

• Start a free 30-day trial: app.cosmicjs.com/signup

• Walk through your current access model with us: book 30 minutes with our CEO

For the architecture underneath the permissions, read the multi-property content stack. For what happens to your schemas without that structure, read content model drift.