Roles & Access Control
Roles decide which DB DevOps sections a person sees and where they can make changes. The sections are Configuration, Change Management, Schema, Governance and Administration; Overview is always shown. A person has the sections of their built-in role plus those of any custom roles they hold. Besides sections, a custom role can grant Read and export the Audit Log, so an auditor reads the trail without administrator rights. The IDE is open to every signed-in user and does not depend on sections.
What a section allows
Without a section, its pages are hidden and the server refuses changes there with 403 SECTION_REQUIRED, for example Your roles do not include Change Management, so you cannot make changes there. Reading is not refused, so other pages that show the same records still load.
| Section | Changes it covers |
|---|---|
| Configuration | Environments, groupings, DB DevOps connections, Repo Sources and object consumers |
| Change Management | Migration scripts, releases, approvals, executions, deployments, decision snapshots and shadow runs |
| Schema | Schema Ops, Seed Data, lint and preflight checks |
| Governance | Compliance rules and AI agent runs |
| Administration | Users, roles, the Audit Log and Settings |
Sections add to the checks each action already makes: running an execution, for example, needs both the Release Manager or Admin role and Change Management. Admins always have every section.
Built-in roles
Every user has one built-in role, Admin, Release Manager, Approver or User, set on the Users page or by the identity provider’s role mapping. Under Administration → Roles you can change a built-in role’s description and sections. Built-in roles cannot be renamed or deleted, the Admin role always has every section, and only the Admin role can include Administration, because those pages need the admin role.
Custom roles
Choose Add Role and give the role a name of up to 100 characters (no other role may have it, in any letter case), an optional description of up to 500 characters, the sections it grants and, optionally, the identity-provider groups that grant it. A custom role adds sections; it never removes any. Deleting a custom role takes it away from everyone who had it.
Each card shows the role’s description, its access (the sections it grants, and Read and export the Audit Log when it grants that) and number of members; the icon marks it as built-in or custom (hover it). Open a role to see its details, then Members for who has it.
Assigning custom roles
Under Assign Roles to a User, select a user, tick their custom roles and choose Save Assignment. Built-in roles are not offered here; change a person’s built-in role on the Users page. Changes apply on the user’s next request.
Single sign-on groups
Each time a single sign-on user signs in, their group claims are compared with every custom role’s identity-provider groups, ignoring letter case. When any match, the user’s custom roles become exactly the matching ones, replacing any assigned by hand; when none match, their custom roles stay as they were. Built-in roles do not take groups. See Mapping IdP Groups to Roles on the Identity Providers page.
Default sections
| Role | Sections |
|---|---|
| Admin | All, including Administration |
| Release Manager, Approver, User | All except Administration |
Audit
Every change is recorded in the Audit Log under the administrator who made it: CREATE_ROLE; UPDATE_ROLE with what changed, including the sections and groups added and removed; DELETE_ROLE with what the role granted and who had it; and ASSIGN_ROLES with the custom roles added and removed for the user. Refused changes are not recorded as role changes.