Members and roles

Settings → Organization → Members and roles (/organizations/{org}/settings/organization/people) is the one place the organization’s people are administered. It folds together three screens that used to be separate - the member list, invitations, and workspace role bindings - because they are one job: getting the right people into the organization with the right standing.

It has two tabs, and they are gated separately:

The section itself carries the weaker of the two, so an organization on an open-source build still administers its own members. See Roles for the second tab.

Membership mutations are privileged and infrequent, so the endpoints carry a tighter rate limit (30 requests/minute) than the API default.

What this page is not

It administers memberships and bindings, not accounts. The sign-in account itself - and the installation-wide platform-admin flag - belongs to the Admin Console, under Platform members. Three tiers, three objects:

Those tiers were briefly folded together, and it went badly enough to be worth stating: an installation-wide account list shown on an organization page listed people who belonged to a different tenant, and creating an account from an organization page produced someone who was a member of no organization at all.

Assigning an organization role

Each member holds exactly one organization-scope role: Owner, Admin, Member, Viewer, or a custom role. Assigning is idempotent - it replaces any existing binding rather than stacking.

For what each role grants, see Roles and permissions.

The assignment goes through two guards, and both return an error rather than doing something surprising:

• Owner-last. The organization must never be left without an Owner. Demoting or removing its only Owner is refused, which is what stops an accidental lock-out.
• No self-escalation. You cannot grant a role above your own level, and you cannot touch a member who already outranks you. An Admin can manage Members and Viewers; only an Owner can create another Owner.

A role change flushes that user’s cached permissions immediately, so it takes effect on their very next request rather than after a cache window.

Removing a member

Removing a member drops their organization binding and their membership. It does not delete their sign-in account - that is an installation-level operation under Platform members. The owner-last and outranking guards apply here too.

You cannot remove yourself. Your own row says so instead of offering the button, and the engine refuses the request. Removing yourself is leaving the organization rather than managing a member: your session would outlive the membership, and the organization would disappear at the next reload with nothing said. Another Owner or Admin removes you.

Workspace roles

Managed services. Requires the workspace-scoped-RBAC feature, and workspace.member:manage.

The Workspace roles column shows how many workspaces a member holds a role in (No workspace, 1 workspace, N workspaces). Expanding the row lists every workspace of the organization, one per line, each with its own role select, where No workspace role removes the binding. You change a person’s placement across the organization from their row, without switching workspace.

Without workspace.member:manage the expanded rows are read-only: they show each workspace role as text. That permission is separate from org.member:manage, which opens the tab, so a custom role can read the list without being able to place people in workspaces. An invitation shows no workspace roles until it is accepted.

The invite form is the exception - it offers the whole workspace list, because choosing the target workspace is the point of a creation control. It defaults to the workspace you are acting in.

A workspace binding replaces the organization baseline for agents in that workspace - it grants what the org role lacks and revokes what it grants. See Workspaces.

Adding people

Both paths live on this page:

• Invitations (managed services) - send a token link; the holder creates their own account and lands in the organization with the role you chose. If the installation has a mailer configured the link is emailed; otherwise the response hands it back for you to deliver.
• Add an existing account - place someone who already has a sign-in account into this organization.

Creating the sign-in account itself is done from Platform members.

Audit

Organization and workspace role assignments and removals are recorded in the authorization audit with the acting operator, the target user, and - for a workspace binding - the workspace.

See also

• Roles and permissions
• Roles - the second tab of this section.
• Workspaces
• Invitations