Understand roles and permissions

not24get controls who can do what through three layers:

Tenant roles — your role on the tenant (the organization that owns workspaces). Every account has exactly one tenant role per tenant.
Custom RBAC roles — fine-grained, permission-based roles that admins can create on top of the built-in tenant roles.
Folder share permissions — per-folder access granted via share links or invites, independent of the role system.

Built-in tenant roles

Role	Purpose	Can do	Cannot do
admin	Operates the tenant	Everything: invite and remove members, create and delete workspaces, manage roles, RBAC assignments, and groups, manage billing	—
member	Day-to-day user	Create workspaces, view org units, view roles, view group and assignment lists	Manage other members, manage billing, write RBAC roles or assignments
support	Read-only operator	View org units, view roles, view RBAC assignments	Modify any data, create workspaces, manage billing

RBAC permissions

Custom RBAC roles are built from a fixed set of permission keys. Admins can compose these into roles and grant them in addition to the built-in tenant role.

Permission key	Grants
`org:units:read`	Read the organization unit tree
`org:units:write`	Create and modify organization units
`rbac:roles:read`	Read the list of roles
`rbac:roles:write`	Create, edit, and delete custom roles
`rbac:assignments:read`	Read role assignments
`rbac:assignments:write`	Assign and unassign roles
`rbac:groups:read`	Read groups
`rbac:groups:write`	Create, edit, and delete groups
`workspaces:create`	Create new workspaces
`workspaces:delete`	Delete existing workspaces
`members:invite`	Invite new members
`members:remove`	Remove existing members

Groups

A group is a named, tenant-scoped collection of accounts that lets an admin assign one or more custom RBAC roles to many people at once. Instead of granting Editor to fifteen people one by one, an admin grants Editor to the Marketing group and adds those fifteen accounts to the group.

What a group is

Field	Notes
Name	Required. Unique within the tenant.
Description	Optional free text — helpful for explaining what the group is for.
Members	Any account in the same tenant.
Role assignments	Zero or more custom RBAC roles attached to the group. Built-in roles (admin / member / support) and folder share permissions are not granted via groups.

Groups live at the tenant level. They are not bound to an organization unit or a workspace, so the same group can be used across the whole tenant.

How permissions work through groups

Inheritance is implicit. Members of a group inherit every permission attached to that group's role assignments. There is no per-member copy — the group is the source of truth.
Permissions union. An account can be in any number of groups. Their effective permissions are the union of every direct role assignment plus every role assigned to a group they belong to.
Evaluated per request. Effective permissions are recomputed on every request, so adding or removing a member takes effect on the next request the member makes. Existing browser tabs do not need to refresh; the next API call sees the new permissions.
No session revocation. Removing a member from a group does not invalidate their JWT or sign them out. They simply lose the inherited permissions on the next request. If you need to lock someone out completely, revoke their tenant membership instead (see Assign and change roles).
Scope follows the role assignment. If you assign a role to a group at workspace scope, the group's members inherit that role only inside that workspace. Tenant-scope assignments apply tenant-wide.

Things groups cannot do

No nesting. A group cannot contain another group. Build flat groups and let an account belong to multiple groups when you need overlap.
No cross-tenant membership. A group is owned by exactly one tenant; you cannot share a group between two tenants.
No built-in tenant role. You cannot make group membership confer the admin, member, or support role — those are tied to the individual tenant membership and must be set per account.
No system groups. Every group is created by an admin and can be deleted. There are no protected, vendor-defined groups.

Who can manage groups

Reading the group list and member counts is available to anyone with the rbac:groups:read permission — that is, every admin and member, but not support.
Creating, editing, deleting, and assigning roles to groups requires the admin tenant role. The Roles & permissions page at Settings → Roles & permissions (/settings/roles) is gated to admins.

Folder shares are separate from the role system. They are tied to a single folder and granted via share link.

Permission	What recipients can do
`read`	View the folder, its bookmarks, notes, and tags. No edits.
`read_write`	Everything `read` allows, plus add, edit, move, and delete bookmarks within the folder.

What's next

Assign and change roles — how admins grant tenant roles, custom RBAC roles, and group memberships.
Invite members to your workspace — the invitation flow.
Share a folder in read-only mode and Share a folder with read and write access — folder-level access.