Roles and Permissions

Every member has exactly one base role in a workspace. It is not a job title and it is not a ceiling — it is the minimum access that person has everywhere in the CMS, which anything else can only raise. There are six roles, they are strictly ordered, and each one includes everything the roles below it can do.

The six roles

Those six labels are the complete set — there is no seventh role, no “Owner”, and no separate billing or developer role. Billing and developer access are granted a different way, described below.

The stored key column matters more than it looks. The label is what the CMS shows you; the key is what API responses, MCP payloads and error strings actually contain, so a Content Publisher appears as Publish in a permissions payload and a Read Only member as Read. If you are reading a response rather than a screen, that is the column to match against.

Which action needs which role is a longer answer than a six-row table can carry. The full list — all 58 privileges and the minimum role each one needs — is in the Privilege Matrix.

A role is a floor, not a ceiling

When Leed decides whether you may do something, it asks two questions in order. First: does your base role reach the minimum role for this privilege? If it does, you are allowed, and nothing else is consulted. Only if it does not does Leed look for an override on the resource you are touching, and ask whether that override reaches the same minimum.

Effective access is therefore the stronger of (base role, applicable override). Overrides only ever raise access. There is no mechanism anywhere in Leed for lowering someone’s access below their base role on a particular page, label or page type — if you need someone to not see something, the answer is a weaker base role plus targeted grants, never a negative exception.

flowchart TD
    A["A privilege is requested<br/>for example page:publish"] --> B{"Does the base role<br/>meet the minimum role<br/>for this privilege?"}
    B -- yes --> ALLOW["Allowed"]
    B -- no --> C["Fetch this member's<br/>access overrides"]
    C --> D["Keep only the overrides<br/>on the resources in play:<br/>this page, its page type,<br/>its labels"]
    D --> E{"Is any surviving override<br/>at or above the<br/>minimum role?"}
    E -- yes --> ALLOW
    E -- no --> DENY["403 Unauthorized: missing page:publish"]

Two details in that diagram surprise people. The override lookup is lazy — it never happens when the base role already suffices, which is why an override can sit unused for months and then start mattering the moment someone is demoted. And the comparison is at or above, not equal: a Content Manager grant (Content Publisher level) on a label satisfies a check whose minimum is Content Writer, because it is stronger.

When a check fails, the response is a 403 whose body names the privilege verbatim:

Unauthorized: missing page:publish

That string is searchable. If you have one in front of you, look the privilege up in the Privilege Matrix and it will tell you the minimum role that clears it.

Where the extra access can come from

There are exactly three ways a member ends up with more access than their base role, and each has its own page.

To raise someone’s access on one page type or one label without changing their role, use Resource-Level Access Overrides. Billing and developer access are granted as overrides rather than as roles, which is why they are checkboxes and not entries in the role dropdown — Billing and Developer Access has the detail. And a byline grants page access on its own, without anyone ticking anything; Authors and Contributors explains how far that reaches and where it stops.

What Content Approver actually does today

Content Approver sits between Content Writer and Content Publisher in the ladder, and it is a real, grantable role. What it is not, today, is an enforced approval gate.

What the role genuinely gives you is two things. It sits above Content Writer in the ladder, so an Approver clears every check a Writer clears and a few a Writer does not — and it is a level you can grant on a single resource through the Approver picker on a label or a page type, which is a useful middle rung when Content Manager is too much and Contributor is too little.

There is one approval gate in Leed that is real, and it is not on pages. Approving a campaign deliverable is gated on contact:publish, minimum role Content Publisher. That is deliverable approval on Campaigns and Deliverables, reached from the Plan Calendar — and it is the only place in the product where an approval action is enforced by a permission check.

If your team wants sign-off before publication, build it out of what is enforced: give writers Content Writer, keep page:publish with a small group of Content Publishers, and let the fact that a writer cannot publish be the gate. That works on every plan and needs no configuration.

Approval is not a paid feature

Which plan you are on changes which features exist, not what your role may do. That split, and the per-feature minimum tier for everything that is genuinely gated, is set out in Feature Availability by Plan.

Where a role is stored, and the second role behind it

A role belongs to a pair: one member, one workspace. The same person can be an Administrator in one workspace and Restricted in another, and neither role knows about the other. A newly created member starts at Read Only.

Behind the Leed role there is a second, much smaller one. Leed mirrors each member’s role into the workspace’s organization record as either admin (for Administrator) or member (for every other role). That mirrored role governs organization management only — inviting people, removing them, updating the organization — and it is the reason an invitation you sent as “Content Writer” is listed as member while it is pending. Everything inside the CMS is decided by the Leed role, not by that one.

Set a member’s role from the row dropdown on Managing Team Members. It applies on selection, with no save step.

Choosing the right role

• Administrator — workspace owners and anyone who has to manage the team, billing or workspace settings. Keep this group small; it is the only role that can invite or remove people.
• Content Publisher — the people responsible for what goes live. They create and publish pages, manage labels and forms, run deployments, and can change other members’ roles and profiles.
• Content Approver — a reviewer, on the understanding that their sign-off is a convention your team keeps rather than a gate the product enforces. Its practical value is as a per-resource grant: the middle option in the override pickers.
• Content Writer — your writers and designers. They draft and revise pages and manage the assets that go with them, while Publishers control what is created and what ships.
• Read Only — everyone else at the company who should be able to read internal content without changing it.
• Restricted — external contributors and agencies. Pair it with overrides to open exactly the content they work on and nothing else.

What each role can even see — which tabs appear in the rail, which cards appear in Settings — is a separate question from what it may do, and it is answered in Who Can See What.

What roles do not control

Three things a role is regularly blamed for and is not responsible for:

• Plan features. A role never decides whether a feature exists in your workspace; your plan tier does. An Administrator on Free still cannot use a Growth-only feature, and no role change will fix that.
• Reducing access. Roles and overrides only ever add up. Nothing in Leed subtracts access from a base role on a specific resource.
• Hiding a page from its author. A page marked private is hidden from everyone except the person who created it, regardless of role — an Administrator does not see it either. That behavior belongs to the page rather than to the role ladder, and it is described on Private Pages.