Resource-Level Access Overrides

A member’s base role applies everywhere in the workspace. An override raises it on one thing — one page type, one label, one page — and changes nothing anywhere else. That is how you give an outside writer the run of your release notes without letting them near your pricing pages, and how a team lead publishes their own section while staying read-only in yours.

Overrides come in two shapes. Most are per-instance: they name a specific page type, label or page, and you grant them on the resource itself. Two are singletons — the Billing and Developer checkboxes on a member’s row, which are covered in Billing and Developer Access because they open administrative screens rather than content.

What can carry an override

The contact resource exists so that contact and lead routes can scope their permission checks to it deliberately; nothing in the CMS grants it, and you can ignore it unless you are writing against the API.

How effective access is worked out

Every gated action names a privilege, and every privilege has a minimum role. Leed checks your base role first. If your role is at or above the minimum, you are allowed and no override is ever read. Only when the base role falls short does Leed fetch your overrides, narrow them to the resources in play, and look for one at or above the same minimum role.

That means effective access on a resource is the stronger of your base role and any override that applies to it. An override can only ever raise access. There is no way to grant an override that takes something away — a Content Publisher whom you add to a Contributor picker is still a Content Publisher on that resource.

The mechanical detail that surprises people is how wide the net is on a page. A page check does not look at the page alone. It builds a resource list of the page, its page type and every label the page carries, and any one of those — plus a byline on the page — can satisfy the check on its own.

flowchart TD
    START["Someone opens a page and Leed checks page:write"] --> BASE{"Is their base role<br/>Content Writer or stronger?"}
    BASE -- Yes --> ALLOW["Allowed — overrides are never read"]
    BASE -- No --> FETCH["Fetch this member's overrides,<br/>narrowed to this page's resources"]
    FETCH --> P["An override on this page"]
    FETCH --> T["An override on the page's page type"]
    FETCH --> L["An override on any label the page carries"]
    FETCH --> A["A byline — author or contributor<br/>on the latest revision"]
    P --> ANY{"Is any one of them at<br/>Content Writer or stronger?"}
    T --> ANY
    L --> ANY
    A --> ANY
    ANY -- Yes --> ALLOW
    ANY -- No --> DENY["403 Unauthorized: missing page:write"]

The four branches are alternatives, not requirements. This is why a Restricted contributor can open a page nobody explicitly granted them: they are on its byline, and the byline is a grant of its own. Authors and Contributors explains exactly how far that reaches.

Granting access on a page type or a label

The control is the same in both places. Open Settings → Page Types (/settings/pages) or Settings → Labels (/settings/labels), click the chevron to expand an item, and three member pickers appear at the top of the expanded panel.

Add a member to a picker and they appear as a chip; hover a chip to see that member’s email address, which is how you tell two people with the same display name apart. Changes apply the moment you make them — there is no save step. Leed confirms each one with a toast reading “Permission Granted” or “Permission deleted.”

The page-type pickers sit inside the detail panel described in Configuring a Page Type; on labels they sit in the expanded label row covered by Labels and Series.

The three pickers

Two honest notes on that table. Content Manager does not include creating pages — creating a page is not an action on any existing resource, so the check is never narrowed to one and only a base role of Content Publisher satisfies it. And Approver does not gate an approval step, because Leed does not enforce one: page:approve is defined but checked nowhere, and moving a page into an approved state goes through the ordinary page-update path. Grant Approver when you want someone to rank as a reviewer on a section; do not expect it to block a publish. Roles and Permissions sets out the ladder and what each rung really enforces.

The pickers are gated in the interface as well. All three render disabled unless you hold rbac:write — the same front-end check that grays out the role dropdown on Settings → Team Members — so an inert picker that still lists names is that gate rather than a plan limit. The write itself is enforced on user:write server-side; Privilege Matrix records the split.

Why someone is missing from a picker

A picker only offers members whose base role is weaker than the level the picker grants. You cannot add a Content Publisher to the Contributor picker, because there is nothing to grant them — they already publish everywhere. Administrators never appear in any picker for the same reason.

If a name you expect is missing, check that person’s role on Settings → Team Members first. Nine times out of ten they already have the access you were about to grant.

One override per person per resource

A member holds at most one override per resource. Adding someone who is already in the Contributor picker to the Content Manager picker on the same label replaces their level rather than stacking a second grant — the underlying row is keyed on the member and the resource, so the new level overwrites the old one. Removing them from a picker deletes the row and drops them back to their base role.

Deleting a page type removes every member’s override on it in the same operation, so a deleted type leaves nothing dangling.

What happens below the Starter plan

On Free, the page-type and label pickers stay exactly where they are. What changes is that they have nothing to add: the member list inside each picker is empty, an attempted addition is dropped and the selection reverts, and a banner above the Labels and Page Types lists explains why. Removals still work, and every override you already have keeps enforcing.

Over the API, the same gate answers POST /api/rbac with HTTP 402 when the override’s resource type is pagetype or label:

{
  "error": "upgrade_required",
  "reason": "feature_gated",
  "feature": "contentRbac",
  "requiredTier": "starter",
  "currentTier": "free"
}

Reads, deletes and enforcement are ungated on every tier, which is the deliberate promise: a workspace that downgrades keeps its existing overrides working and can still take them away. For what a 402 looks like elsewhere in the interface and which other features behave this way, see When a Feature Is Gated.

Per-page access

There is no per-page picker in the CMS. Page-level access arrives one of two ways: someone is listed as an author or a contributor on the page, which grants Content Writer level on it automatically, or an integration writes a page override through the API. A byline does the per-page job without an override at all, and it is free on every plan — see Authors and Contributors.

The classic case: an outside contributor

You have hired a freelancer to maintain your release notes and nothing else.

1. Invite them with the Restricted role. Inviting People walks through the invitation and the follow-up step that sets their real role. A Restricted member signing in for the first time sees almost nothing: two tabs in the rail and an empty page tree.
2. Open Settings → Page Types, expand the Release Notes type, and add them to the Contributor picker.

They can now see every page of that type in their page tree and edit those pages. They cannot create a new release note, publish one, or see a page of any other type. Have a Content Publisher create the page shells they will fill in — that is the one step this arrangement always needs.

Patterns that work

Team-scoped publishing. A team lead stays Read Only as their base role and goes into the Content Manager picker on their team’s label. They publish anything carrying that label and read everything else.

A reviewer on one section. Add a subject-matter expert to the Approver picker on a page type so they outrank its writers and can edit its pages. Treat the sign-off itself as a team convention rather than a gate the software enforces.

Billing and developer delegation works the same way but with a checkbox rather than a picker, and it is granted on the member’s row instead of on the resource — see Billing and Developer Access.

What an override does not do

It cannot lower access. It cannot let anyone create a page — page:create needs a base role of Content Publisher, and a Contributor override grants Content Writer level on pages that already exist. And it has one side effect worth knowing before you hand out the first one.

Which screens that actually adds, role by role, is mapped in Who Can See What. The complete list of privileges each level satisfies is in the Privilege Matrix.