Everyone who belongs to your workspace appears on Settings → Team Members (/settings/team), under the heading “Control members of your organization and configure permissions.” This page is the screen itself: what each control on a member row does, and which of them your own role lets you touch. Adding someone who is not in the workspace yet starts at Inviting People; what the roles in the dropdown actually mean is Roles and Permissions.
Team management costs nothing. It is not gated by your plan, and the pricing page sells unlimited users on every tier, including Free — Leed does not charge per seat, so the size of your team is never a reason to upgrade.
Role, privilege, override and workspace membership are four separate ideas, and this category keeps them distinct throughout — if any of them is new, the Glossary defines all four in one place.
Who can do what on this screen
Not every control here hides itself when you are not allowed to use it. The clearest example is deletion:
Everything else on the screen behaves the way you would expect — a control you cannot use is disabled or absent.
| Action | Control | Privilege checked | Minimum role | Note |
|---|---|---|---|---|
| List the members | the screen itself | none — GET /api/user carries no permission check | any signed-in member | The Settings card that links here is gated on user:read, so a Restricted member has no route to the screen through navigation |
| Change someone’s role | role dropdown | rbac:write | Content Publisher | The dropdown is disabled, not hidden |
| Tick Billing or Developer | checkboxes | rbac:write | Content Publisher | Writes an access override, not a role |
| Edit Available to Templates or Slug | expanded row | user:write | Content Publisher | |
| Open Invite Member | header button | user:create | Administrator | The button is not rendered at all below Administrator |
| Edit a member’s profile | ⋮ → Edit | user:write, or it is your own profile | Content Publisher, or yourself at any role | |
| Remove a member | ⋮ → Delete | user:delete | Administrator | Menu item is not gated in the interface — see the warning above |
Two privileges do the work here, and they sit at the same rung: rbac:write (a front-end gate on the role dropdown and the two checkboxes) and user:write (what the server actually checks when the change is saved). Both have a minimum role of Content Publisher, so the answer a reader cares about is the same either way. The full list of privileges and the role each one needs is in the Privilege Matrix.
Reading a member row
Every member is one row. Left to right:
| Element | What it shows | Editable by |
|---|---|---|
| Chevron | Expands the row to reveal the site profile fields | anyone (it is a disclosure control) |
| Avatar | The member’s profile image, or their initials | the member, on their own profile |
| Name | First and last name | Content Publisher, or the member themselves |
| Amber dot | “Must be published to be active” — this member’s profile has changes that are not on the published site yet | not a control |
Since <Month Year> | When the membership was created | not editable |
| Role dropdown | The member’s base role, by its display name | Content Publisher (rbac:write) |
| Billing checkbox | Whether the member holds the billing access override | Content Publisher (rbac:write) |
| Developer checkbox | Whether the member holds the developer access override | Content Publisher (rbac:write) |
| ⋮ menu | Edit (opens the member’s profile) and Delete | Edit: Content Publisher or self · Delete: Administrator |
The Billing and Developer checkboxes are access overrides rather than roles, which is why they sit beside the role dropdown instead of inside it — Billing and Developer Access says exactly what each one opens and why a checkbox sometimes arrives already ticked and grayed out.
When the workspace has unpublished member changes and you hold the right to publish, the screen header also carries an Unpublished changes — Publish shortcut through to Deploy.
Changing someone’s role
What the dropdown does
The dropdown lists all six roles by their display names — Administrator, Content Publisher, Content Approver, Content Writer, Read Only, Restricted — strongest first. Choosing one applies it immediately: there is no save button and no confirmation step. If the dropdown is disabled, your own role is below Content Publisher.
A role change is instant for the CMS, but it is not retroactive in the way people sometimes assume. Lowering someone’s role does not remove any override they already hold, because an override can only ever raise access. Someone demoted to Read Only who still holds a Contributor grant on a page type keeps Content Writer access on that page type.
The second role you did not know you changed
Leed keeps two role systems, and this dropdown writes to both.
The role you pick is stored in cms_org_members.role and governs everything inside the CMS. At the same time, the change is mirrored into the workspace’s Better Auth organization record through a one-way collapse: Administrator becomes admin, and every other Leed role becomes member. That second role governs organization management — inviting people, removing them, updating the organization — and nothing else.
You will not normally see the Better Auth role, with one exception: it is the role printed on each row of the Pending Invitations block, which is why an invitation you sent as “Content Writer” shows up there as member. Inviting People picks that thread up in full.
The amber dot: member changes must be published
Member profiles are part of your published site, not only of the CMS. When you publish, Leed writes every member into the site repository as src/_data/userList.json, which is what author templates read. So editing a member’s profile stages a change exactly like editing a page does: the amber dot appears next to their name, the header offers the Deploy shortcut, and the change reaches your live site on the next deployment.
Like everything else you change in the CMS, this rides the next deployment — Publishing Changes covers what a publish does and how to see what is queued.
Site profile fields on the expanded row
Click the chevron on the left of a row to reveal the two fields that control whether this person can appear on your published site.
Available to Templates
This checkbox sets the member’s visible flag, which is what makes their record available to your site templates — an author index, a byline, a contributor list.
Ticking it is necessary but not always sufficient. When Leed writes userList.json at publish time, any member without a slug is forced back to invisible, whatever the checkbox says. A member with the box ticked and the slug blank publishes as hidden, silently and with no error.
Slug
The slug is the identifier your author templates look a member up by. It is slugified as you type — spaces become dashes, accents and punctuation are normalized — saved one second after you stop typing, and flushed immediately when you leave the field, so a slug you type and then navigate away from is still saved.
The field is disabled unless Available to Templates is on and you hold user:write. The slug and the visibility flag together are what let a member appear as a byline on your published site; Authors and Contributors covers the other half of that story — the byline itself, and the page access it quietly grants.
Editing a member’s profile
Choose ⋮ → Edit on a row to open the member’s full profile at /user/:userId: name, job title, department, biography, phone, country, language and profile image. You can edit it if you hold user:write or if it is your own profile — every member can edit their own, at any role.
One field is fixed. Email cannot be changed, on any profile, at any role: the API rejects a changed address with 400 Unable to change email. A person who needs a different address needs a new membership.
Every field on the profile screen is listed in Your Profile, written from the member’s own point of view.
Removing a member
Choose ⋮ → Delete on the member’s row. This is an Administrator action, and — as noted at the top of this page — the menu item does not hide itself from anyone else, it simply fails.
Removing a member does three things:
- Soft-deletes their CMS membership, so they lose access to this workspace. It takes effect on their next request; an open browser tab does not keep working.
- Removes their Better Auth organization membership.
- If that was their last membership anywhere in Leed, deletes the OAuth accounts linked to their login, so the same Google or GitHub identity can be attached to a fresh login later without colliding.
A member who belongs to more than one workspace keeps their other memberships and their linked accounts — removal is scoped to this workspace only. Joining and Switching Workspaces describes what that looks like from their side.
If the member you removed had a slug, their removal is also a site change: the member list is marked dirty and the amber-dot rule above applies, so their byline stays on the published site until the next deployment.