Every member row on Settings → Team Members carries two checkboxes: Billing and Developer. They are not roles and not part of the role ladder. Each is an override that grants Administrator level on one fixed resource — the billing resource, or the developer resource — and changes nothing else about that member. Tick Billing on a Read Only member and they can pay your invoices; they still cannot edit a page.
Both checkboxes work on every plan, Free included. They are administrative access delegation rather than the content-governance feature that carries a plan gate, and the code that gates page-type and label overrides deliberately carves them out. These two sit on the member rows described in Managing Team Members; for access to content rather than to these two areas, you want Resource-Level Access Overrides instead.
| Checkbox | Privilege granted | Level granted on the resource | Base role that already has it | Gated by plan? |
|---|---|---|---|---|
| Billing | billing:write | Administrator on the billing resource | Administrator | No |
| Developer | developer:write | Administrator on the developer resource | Content Publisher | No |
What Billing opens
The Billing & plan card appears on Settings Home, and /settings/billing becomes reachable: the plan chooser, the payment method, order history and invoices. Every billing API route is gated on the same privilege — reading the subscription, changing the plan, canceling it, and minting a checkout link.
One route is deliberately open to anyone who can read the company: the usage read behind the meters. Contact counts and email volume are non-PII aggregates, and the over-limit banner has to render for the people who are actually hitting the limit, not only for whoever pays. So a member without Billing still sees how much of the plan is used — they only cannot act on it. Everything behind that screen, including who is allowed to run a checkout, is in Managing Your Subscription.
The second effect is the one people miss. Upgrade prompts appear all over the CMS when a feature is above your plan, and the prompt reads the same privilege to decide what to offer. A member with Billing gets an Upgrade plan button that takes them straight to the plan chooser. Everyone else gets the sentence “Ask your account admin to upgrade your plan.” Ticking this box therefore changes what a member sees on a gated feature, not only what they can pay for — When a Feature Is Gated shows both versions side by side.
What Developer opens
In the interface, exactly one thing: the Developer Setup item in the profile menu, which opens the credentials modal that the Leed CLI needs to authenticate. Behind it sits the API surface the CLI and the Layouts workspace actually use.
| Surface | Where it appears | Note |
|---|---|---|
| Developer credentials | Developer Setup in the profile menu | Issues the registry and content tokens, and can rotate them |
| Credential status | The same modal | A pure read: which tokens exist and when they expire |
| CLI install configuration | Consumed by the CLI, not shown in the CMS | The config and package-registry details leed installs against |
| Site template files | The Layouts workspace | Listing, reading and writing the site’s template files |
| Email layout files | Settings → Emails | Creating, reading and updating an email layout; the list of templates is gated on contact:read instead |
| The site push endpoint | Called by the CLI after a push | Starts a build from a repository push |
The credentials the modal hands out are what CLI Authentication consumes, and the template files it unlocks are the ones you edit in the Layouts Workspace.
Why a checkbox is ticked and grayed out
Some rows show a checkbox that is already ticked and cannot be clicked. That is not a bug and it is not a permission you are missing.
billing:write has a minimum role of Administrator, and developer:write has a minimum role of Content Publisher. So every Administrator shows both boxes ticked and disabled, permanently. Every Content Publisher shows Developer ticked and disabled, and Billing clear and clickable. The checkboxes only mean something on the roles below those lines — which is why the Developer box looks useless on a Content Publisher row until you know that developer access is a Publish-level privilege in the first place. Both privileges and their minimum roles are listed in the Privilege Matrix.
Who can tick them
Both checkboxes are disabled unless you hold rbac:write — Content Publisher and up. That is the same gate as the role dropdown next to them.
Two patterns worth copying
Removing access
Untick the box. The override row is deleted immediately — there is no save step and no publish — and the member falls back to their base role on their next request. If the box will not untick, the access is coming from their role rather than from the override; see Why a checkbox is ticked and grayed out.
Removing a member from the workspace is a different operation with a different consequence: it takes away their membership, but it does not clean up override rows. Managing Team Members covers removal.