Roles

A role is a named bundle of permissions, attached to one node in the organization tree. Members assigned that role at that node receive its permissions.

The Roles & Permissions tab

Selecting a node opens its detail panel; the Roles & Permissions tab is the second tab.

The layout has two columns:

• Left — the list of roles defined at this node, plus a Create role action at the bottom (visible if you have manage roles).
• Right — the selected role's detail, with two sub-tabs: Members (who has the role) and Permissions (which permissions it grants).

Visibility:

• With permission to manage roles: you see every role at this node and can edit them.
• Without it: you see only the roles you hold. Read-only.

Creating a role

Click Create role. The modal asks:

• Name (required) — what people will call this role in conversation.
• Propagate to child teams (toggle) — see Propagation below.

Roles are created with no permissions. Open the new role's Permissions tab and toggle on what it should grant.

Editing role permissions

The Permissions sub-tab groups the catalogue by category — Administration, Reporting, Configuration & Operations, Clients. Each row is one permission with its display name, a short description, and a toggle.

Toggling changes are batched:

• The bottom of the panel surfaces Save and Discard buttons once you've made unsaved changes.
• Save commits.
• Discard reverts.

You can flip multiple toggles before saving. There's no per-toggle save.

Propagation

The propagating flag on a role decides whether its permissions reach down into sub-teams.

• Propagating role at Team X → the role's permissions apply at Team X and every Sub-team under it.
• Non-propagating role at Team X → the role's permissions apply only at Team X.

Pick propagation when:

• The role is an "above-the-line" role (admin, lead) that should govern the whole branch.
• You'd otherwise have to copy the role into every sub-team.

Pick non-propagation when:

• The role is scoped to one team (e.g. Search Manager) and shouldn't apply to sibling sub-teams.
• You want to use one team's role to grant access to that team only.

You can change the propagating flag later from the role detail header.

The Owner role

Every Organization has an Owner role:

• Read-only — you can't change its permissions or its propagation toggle.
• Always propagates — Owners have every permission at every node, regardless of the toggle.
• Protected — Level refuses to modify Owner's permissions, delete the Owner role, assign Owner via the normal Manage access flow, or remove someone from Owner.

Practically: Owner is the "break-glass" role. Workspaces typically have 1–3 Owners; everyone else has narrower roles.

Editing and deleting roles

The role detail header has Edit (rename, toggle propagation) and Delete actions, both available if you can manage roles.

Deleting a role:

• Removes the role from every member who held it. Those members keep any other roles they had.
• Owner role can't be deleted — see protection above.

Best practices

• Build a small set of common roles, reuse them across teams. Two or three propagating roles + a handful of non-propagating ones cover most setups.
• Don't build per-person roles — that's what overrides are for. A role meant for one person tends to drift.
• Review periodically. Permission inflation is real — re-check what each role grants every few months and trim.