By Mehdi HassanWhat are CMS roles and permissions?
CMS roles and permissions control who can see, create, edit, publish and delete content in your website's CMS. A role is a named bundle of permissions, such as admin or editor, and each user gets one. Permissions can apply to whole collections, single fields or individual documents.
Getting this right matters more than it seems. Too loose, and someone deletes a page or changes the site's settings by accident. Too strict, and every small change goes through one person who's always busy. Roles are one of the pillars of a good CMS setup for a marketing website, alongside the content model and preview.
Which CMS user roles does a small team need?
A small team needs three roles at most: admin, editor and contributor. Many CMSs ship with more, but extra roles create confusion about who can do what, and most startups never use them.
Role | Can do | Can't do | Typical person |
|---|---|---|---|
Admin | Everything: users, settings, integrations, all content | Nothing is blocked | Founder, head of marketing, lead developer |
Editor | Create, edit and publish pages and posts; upload media | Manage users, change site settings, edit code-level config | Marketers, content leads |
Contributor | Create and edit their own drafts | Publish, edit others' posts, delete | Freelance writers, product team, guest authors |
Our own site runs on exactly two roles. Admins manage people, leads and site settings; editors change site content only. New users default to editor, and only an admin can change anyone's role. We describe the setup in our article on Payload CMS for marketing sites.
How should you set up roles for teams of different sizes?
Match roles to how your team actually publishes, and add complexity only when a real problem appears. Here's how we'd set up teams of different sizes.
2 to 5 people
Two admins and everyone else as editors. Editors publish directly, and version history covers mistakes. A review step would slow you down more than it protects you.
6 to 12 people
Add contributors for anyone who writes occasionally, such as product managers or freelancers. Their drafts go to an editor for review. Editors still publish directly.
13 to 20 people
Consider scoping editors by section: the blog team edits posts, the product marketing team edits product pages, and only a few people touch the home page and pricing. If you run a multilingual site, scoping by locale lets translators edit only their language.
What should editor permissions in a CMS include?
Editors should be able to do everything about content and nothing about the site's structure. That means creating pages from the existing blocks, editing copy and images, publishing, scheduling and restoring old versions, but not changing global settings, user accounts or integrations.
- Allow: create and edit pages, posts and media; publish and unpublish; reorder lists; restore versions.
- Restrict: deleting published pages (unpublish instead), editing navigation and footer, changing redirects.
- Block: user management, API keys, webhooks, environment settings, roles.
- Hide: anything blocked, so it doesn't clutter their navigation.
Restrictions work best when the CMS's structure already does part of the job. Constrained page builder blocks mean editors can build new pages freely without being able to break the design, so you don't need tight permissions to keep pages on-brand.
How do you set up a content approval workflow?
A content approval workflow is a defined path from draft to published, with a named person who approves. For most small teams it needs only drafts, a status field and a notification, not a dedicated workflow tool.
Turn on drafts
Every post and page starts as a draft that isn't visible on the site.
Add a status field
Use Draft, In review and Approved. Contributors can set In review; only editors can publish.
Notify the reviewer
Send a message to the editors' channel or email when something moves to In review.
Review in preview
Editors check the real page, not the form. Live preview makes this fast.
Publish or schedule
The editor publishes or schedules. Version history records who changed what.
Example: a hypothetical launch-week workflow
For example, suppose a 10-person startup is launching a new feature. A product manager, set up as a contributor, drafts the announcement post and marks it In review. The content lead, an editor, reviews it in preview, edits the headline and schedules it for launch morning.
Meanwhile, the head of marketing, an admin, updates the pricing global. Nobody waited on a developer, and nobody could accidentally publish the post early.
How do you manage CMS access control over time?
Access control isn't a one-time setup. People join, change roles and leave, and the CMS has to keep up. Put a few habits in place from day one.
- Offboard on the last day. Remove CMS access along with email and other tools. Shared logins make this impossible, so give every person their own account.
- Review users every quarter. Remove freelancers who finished, and downgrade anyone who no longer needs a higher role.
- Use single sign-on if your CMS supports it and your team is big enough to justify it, so access follows your company accounts.
- Keep version history on. It answers who changed this when something looks wrong.
If you're moving content between platforms, recreate roles in the new CMS before you invite the team, and give the migration crew temporary admin access you remove afterwards. Our guide to CMS content migration covers the rest of that process.
