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, and tables.

Important! When Domains, Branches, 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`, `TableDefinition`)
Model ID	The specific resource instance (e.g., the Finance domain, the Development branch)

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
`edit`	`edit`	Branch membership for End Users; grants no development actions
`approve`	`approve`	Approve promotions and deployments targeting this branch. Receive notification emails.
`develop`	`develop`	Full development access on this branch

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	`data manager` on the table's domain
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 + `develop` on the target branch
Deploy on a branch	`develop` on the branch
Approve a promotion	`approve` on the target branch
Create a private branch	Account-level `develop` permission
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 and Branch Permissions

Many actions require permissions on both a domain and a branch. This is intentional — it allows fine-grained access control:

Scenario	Domain Permission	Branch Permission	Result
Developer on Finance, Developer on Dev branch	`develop` on Finance	`develop` on Development	Can create/edit Finance table definitions on Development
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 Development	Cannot create table definitions (missing domain access)
End User on Finance Data Manager, Editor on Dev branch	`data manager` on Finance	`edit` on Development	Can view and edit data in Finance tables on Development
Data Manager on Finance, any branch	`data manager` on Finance	N/A	Can view and edit data in Finance tables (data access is branch-independent via the current branch context)

End User Permissions

Users with license type end_user have a restricted permission set:

Allowed Permissions	Not Allowed
`edit` (on branches and table definitions)	`admin`
`data manager` (on domains)	`develop`
	`approve`

End Users are designed for data entry and viewing — they cannot perform development or administrative tasks regardless of group membership.

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)

Result: Can view and edit data in tables within assigned domains.

Developer (Full Access to One Domain)

Groups: - Domain [Name] Developer - Domain [Name] Data Manager - Branch Development Editor - Branch Development Developer

Result: Can create table definitions, edit data, and deploy on the Development branch for one domain.

Approver (Test/Production)

Groups: - Branch Test Approver - Branch Production Approver

Result: Can approve promotions and deployments to Test and Production branches.

Full Admin

Groups: - Account Administrator

Result: Full access to everything. No other groups needed.

User Groups — managing groups and assignments
Managing Users — user lifecycle
Domains — domain-level access control
Branches — branch-level permissions
Working with Branches — branch permission requirements