CMS user roles and permissions: who should change what
CMS user roles and permissions for client sites: who should change words, who should change structure, and why "admin for everyone" is the expensive default.
At launch, most agencies give the client an admin login. It's quicker than thinking about roles, the client feels trusted, and nobody has to answer "why can't I do that?" in the first week.
Then, months later, it's 4:40 on a Thursday and the homepage hero is gone. Someone on the client's side deleted a section because it looked like a duplicate. Or they changed a setting they didn't understand. Or the intern who was asked to fix a typo also moved the navigation. What to do when a client breaks their own website starts with exactly these scenes.
"Admin for everyone" isn't generosity. It's the most expensive default in client work, because the cost lands on you, unbilled, every time something breaks.
The split that matters
Most CMS user roles and permissions schemes have a long list of checkboxes. Ignore the list for a moment. Two distinctions do nearly all of the work.
Structure versus content. Structure is how the site is built: the content types, the fields, the sections, the templates, the settings. Content is what goes on it: the words, the images, the pages and posts. Most clients need to change content often and structure never. Most agency developers need to change structure and rarely touch content.
Publish versus draft. Some people should be able to put things live. Others should only be able to prepare them for someone else to review. A junior on the client's side, a freelance writer or a stakeholder who wants to suggest changes all belong in the second group.
Get those two lines right and most "the client broke it" incidents stop being possible, rather than merely discouraged. That's the idea behind content control, not design control.
A practical mapping
Here's a mapping that fits most agency sites. It uses five roles, which is what we ship as presets, but the shape works on any platform with roughly equivalent ones.
Owner: the agency principal. Everything, including members and billing. One or two people, not the whole team.
Developer: the agency developer. Changes structure and settings, reads content. Doesn't need to publish the client's words.
Editor: the client's marketing lead. Creates, edits and publishes content. No access to structure or settings.
Author: a contributor. Drafts and edits, but can't publish. Someone else reviews and ships.
Viewer: a stakeholder. Reads only. The managing director who wants to see what's going on without changing anything.
Notice what the client's marketing lead doesn't get: the ability to change a content type, add a field or edit a template. That's deliberate. They didn't ask for it, and it's where the expensive breakages come from.
Custom roles per content type
Real teams don't always fit five boxes. A common case: the client's comms officer should be able to publish news posts, but not touch the main pages, which belong to the marketing lead.
That needs permissions scoped per content type. On Contentive, a custom role is built from a fixed list of capabilities, can be limited to particular content types and is defined once at organisation level, so "News publisher" can be reused on every client site that needs one. Structure and content are separate capabilities, so a role gets one without the other unless you deliberately grant both. Each client is invited to their own workspace only, and seats are unlimited on the Agency plan, so there's no pressure to share one login to save money.
If your platform doesn't support per-type permissions, the fallback is a workflow rule: the comms officer drafts as an Author, and the marketing lead publishes. It's slower, but it holds.
Agents are users too
Once someone connects an AI agent to the site, that agent is another member of the team, and it needs a role like anyone else. The mistake is to hand it the agency's own credentials because that's what was to hand.
Give an agent the narrowest connection that does the job. A read-only connection for audits and reports. A content-only connection for drafting, with no publish, schema or settings tools. Full structure access only for a build, and only on a workspace that isn't live. AI content operations goes into which jobs belong where.
What it costs
Tighter roles mean more requests. The marketing lead who used to change a setting now has to ask. The comms officer who used to edit the homepage now has to go through someone else. Some clients will find that frustrating, at least at first.
The answer isn't to loosen the roles. It's to make the request route easy and priced. "If you need a new section type or a settings change, email us and we'll quote it" is a perfectly good sentence. The request becomes a small paid job instead of an unpaid repair. Our client handover post has wording for that conversation.
There's also a setup cost. Roles have to be chosen at launch, explained in the handover and revisited when the client's team changes. That's a few minutes per site, and it's worth it.
Audit every live site this month
Open each live client site. List everyone with access and what they can do. For each person, ask two questions: do they need to change structure, and do they need to publish? Downgrade anyone whose answer is no. Remove anyone who's left the client's team. Then write down who to contact for structure changes, and put that sentence in front of the client.