Cloud/Settings/Roles
Roles
The permission model of the organization: system roles that come built in, custom roles you compose from the permission catalog, and the rule that system roles cannot be deleted.
Roles is the organization's permission model made visible. The description: "Custom roles and the permissions they grant." Managing it requires org:manage.
Roles
Custom roles and the permissions they grant.
Full control over the organization.
Default access for invited people.
Read-only access for reporting.
Data Analyst
Pick the permissions this role grants within its scope.
Members
Teams
Settings
Audit
The mockup is the real page. Select a role to read its grouped permissions, and note the System badge on the ones that cannot be deleted.
System roles first
Every organization starts with two: Owner, full control, and Member, the default for invited people. Both carry a System badge, and the console refuses to delete them; they are the floor the rest of the model stands on.
Custom roles
Create role opens the editor: a name like "Data Analyst" and the permission picker, where the instruction is "Pick the permissions this role grants within its scope." Permissions come from the organization's catalog grouped by domain, members, teams, settings, audit, and each permission is a concrete capability such as org:members:read or org:manage. A custom role is also Clone-able: duplicating a role and trimming it is faster than starting from zero. Deleting a custom role is a Delete with confirmation; the roles on Members that referenced it need reassigning.
Why this page exists
Permissions here are not decoration: they are the same ABAC checks the console enforces everywhere, deciding who sees the audit trail, who edits SSO, who manages the member list. Roles turn those checks into reusable words. Instead of granting org:audit:read to a person, you grant them Data Analyst, and the meaning travels with the name.
What comes next
Service Accounts applies the same idea to identities that are not people.