Permissions
Available to: Account Administrators Minimum plan: Free
This page explains TitanRDM's permission model in detail — how permissions are structured, what each permission type grants, and how they combine to control access across domains, branches, environments, and tables.
Important! When Domains, Branches, Environments, and Table Definitions are created, one user group is automatically created for each applicable permission, making it easier to assign users to user groups rather than granting permissions to each user. On a day-to-day basis, you give users permissions by adding them to these user groups. This section explains permissions, but it isn't necessary for understanding how to give users permissions. See the User Groups section for more information.
Permission Model Overview
TitanRDM uses a group-based, polymorphic permission model:
Permission = User Group + Action + Permission Type + Resource (Model)
Each permission record has:
| Field | Description |
|---|---|
| User Group | The group that holds this permission |
| Permission | The permission type (e.g., admin, develop, data manager, approve, edit) |
| Action | The action allowed (e.g., admin, develop, data manager, approve, edit) |
| Model Type | The resource type (e.g., Account, Domain, Branch, Environment, TableDefinition) |
| Model ID | The specific resource instance (e.g., the Finance domain, the main branch, the Prod environment) |
Permission Types
Account-Level Permissions
| Permission | Action | Grants |
|---|---|---|
admin | admin | Full access to everything in the account. Bypasses all other checks. |
develop | develop | Account-wide development capability. Required to access Development features. |
Domain-Level Permissions
| Permission | Action | Grants |
|---|---|---|
develop | develop | Create, edit, and delete table definitions within this domain |
data manager | data manager | View and edit data in deployed tables within this domain |
Branch-Level Permissions
| Permission | Action | Grants |
|---|---|---|
approve | approve | Approve promotions targeting this branch. Receive promotion request emails. |
develop | develop | Create and change table definitions on this branch, clone into it, and promote from it |
Environment-Level Permissions
| Permission | Action | Grants |
|---|---|---|
edit | edit | Access to the environment: select it in the environment chooser and work with its data (together with a domain permission) |
deploy | deploy | Deploy changes to this environment. Receive deployment request emails. |
Table-Level Permissions
| Permission | Action | Grants |
|---|---|---|
edit | edit | Edit this specific table definition's columns and properties |
Permission Resolution
When TitanRDM checks if a user can perform an action, it evaluates permissions in this order:
- Account Admin check — is the user in the Account Administrator group? If yes, access granted (bypasses all other checks).
- Specific resource check — does the user belong to a group that has the required permission on the specific resource?
Examples
| Action | Required Permission |
|---|---|
| View/edit data in a table | Access to the table's environment (edit or deploy) + data manager (or develop) on the table's domain or table |
| Create a table definition | develop on the target domain + develop on the current branch |
| Edit column definitions | develop on the table's domain + develop on the table's branch |
| Clone a table to a branch | develop on the table's domain + access to an environment of the source branch + develop on the target branch |
| Create a promotion | develop on the source branch |
| Approve a promotion | approve on the target branch |
| Deploy to an environment | deploy on the environment (owners of a private environment can always deploy to it) |
| Create a deployment to an environment of a shared branch without a promotion | Account administrator |
| Create a private branch | Account-level develop permission |
| Manage shared branches and environments | Account administrator |
| Add/remove users | admin on the account |
| Change plan/billing | admin on the account |
Permission Hierarchy
Permissions do not cascade automatically. Having develop on a domain does not grant data manager — these are separate permissions for separate roles.
However, Account Administrator access is an exception — it grants everything regardless of other group memberships.
Combining Domain, Branch and Environment Permissions
Domains decide which tables a user can work with. Branches decide where they can change table definitions. Environments decide where they can see and edit data, and where they can deploy. Many actions need permissions from more than one:
| Scenario | Domain | Branch | Environment | Result |
|---|---|---|---|---|
| Developer on Finance, Developer on their dev branch | develop on Finance | develop on dev branch | Owner of their Dev environment | Can create/edit Finance table definitions and deploy them to their Dev environment |
| Developer on Finance, no branch permission | develop on Finance | None | — | Cannot edit table definitions (missing branch access) |
| No domain permission, Developer on dev branch | None | develop on dev branch | — | Cannot create table definitions (missing domain access) |
| End user, Finance Data Manager, Editor on Prod | data manager on Finance | — | edit on Prod | Can view and edit Finance data in Prod only |
| Finance Data Manager without environment access | data manager on Finance | — | None | Cannot see any data — they have no environment to work in |
| Developer who can deploy to Prod | — | — | deploy on Prod | Can deploy pending deployments to Prod |
Data Manager permission applies in every environment the user can access: a Finance Data Manager who is an Editor on both Stage and Prod can edit Finance data in both.
End User Permissions
Users with license type end_user have a restricted permission set:
| Allowed Permissions | Not Allowed |
|---|---|
edit (on environments and table definitions) | admin |
data manager (on domains) | develop |
approve |
End Users are designed for data entry and viewing — they cannot perform development, deployment or administrative tasks regardless of group membership. New end users are added to the Editor group of the production environments.
Viewing a User's Effective Permissions
To see what a specific user can access:
- Navigate to Admin > Users
- Click the user's name
- View their User Groups list
- Each group name indicates the scope and role (e.g., "Domain Finance Data Manager")
There is no single "effective permissions" view — permissions are the sum of all group memberships.
Common Permission Configurations
Data Entry User (End User)
Groups: - Domain [Name] Data Manager (for each domain they need access to) - Environment Prod Editor (added automatically for new end users)
Result: Can view and edit data in tables within assigned domains, in Prod.
Developer (Full Access to One Domain)
Groups: - Domain [Name] Developer - Domain [Name] Data Manager - Their own development branch and private environment groups (added automatically) - Environment Editor for each shared environment (added automatically for new developers)
Result: Can create table definitions for one domain on their development branch, deploy them to their own Dev environment, and view the shared branches' definitions to clone them.
Release Manager
Groups: - Branch main Approver - Environment Stage Deployer - Environment Prod Deployer
Result: Can approve promotions into main and deploy them to Stage and Prod.
Full Admin
Groups: - Account Administrator
Result: Full access to everything. No other groups needed.
Related Pages
- User Groups — managing groups and assignments
- Managing Users — user lifecycle
- Domains — domain-level access control
- Branches — branch-level permissions
- Environments — environment-level permissions
- Working with Branches — branch permission requirements