Overview
Role-Based Access Control (RBAC) helps you manage who can view, create, edit, or delete data in your workspace.
It works through a combination of:
- Roles → define what actions a user can perform
- Groups → define what data a user can access
This structure gives you both simplicity and flexibility when managing permissions.
How RBAC Works
1. Roles: What a User Can Do
Every user is assigned a role that defines their maximum level of access.
| Role | Access Level |
|---|---|
| Admin | Full access (view, create, edit, delete) |
| Regular | Can view, create, and edit |
| Viewer | View only |
Important:
- A user cannot perform actions beyond their role
- A user’s role defines what they cannot do
- Even if a group grants additional permissions, actions not allowed by the role will always be blocked
Example:
- A Regular cannot delete records, even if their group allows deletion
- A Viewer cannot edit records, even if their group allows editing
2. Groups: What a User Can Access
Groups control which records or data a user can interact with.
You can use groups to:
- Grant access to specific assets, contracts, or documents
- Limit access to certain teams (e.g., Finance, IT, Legal)
- Define whether users can view or edit within that group
Think of it this way:
- Role = actions
- Group = scope
Read: How to Create and Manage Groups
3. Putting It Together
When a user tries to perform an action, the system checks:
- Role
- Is the action allowed?
- Group access
- Does the user have access to this record?
Both must allow the action for it to succeed.
User Onboarding and Default Access
When a new user is invited to the platform:
- The user is assigned the Viewer role by default for security purposes
- This means they will have read-only access only
After the user accepts the invitation:
- An Admin should update the user’s role if additional permissions are required
- The user must also be added to one or more groups to gain access to data
Important:
- New users will not see any data upon joining
- Access is only granted once they are assigned to a group with the appropriate permissions
Common Use Cases
Example 1: View-Only Access
- Role: Viewer
- Group: Finance
Result:
- User can view finance-related records
- User cannot edit or delete anything
Example 2: Mixed Access Across Modules
Requirement:
- Can edit contracts
- Can only view assets
Setup:
- Role: Regular
- Group 1: Contracts (edit access)
- Group 2: Assets (view-only access)
Result:
- User can edit contracts
- User can only view assets
Example 3: Group Permissions vs Role Limit
- Role: Viewer
- Group: Edit access
Result:
- User can view records
- User cannot edit or delete
Even though the group allows editing, the Viewer role limits the user to read-only access.
Data Visibility
Users can only see records that are:
- Assigned to them
- Shared with them
- Available through their group membership
If a user does not have access, the record will not appear in their view.
Best Practices
- Assign roles based on responsibility, not convenience
- Use groups to manage access at scale
- Avoid giving Admin access unless necessary
- Keep group structures aligned with teams or functions
FAQs
Can a Viewer ever edit records?
No. Viewers are limited to read-only access.
Can a group override a user’s role?
No. Roles always take precedence over group permissions.
Can I control access per module (Assets, Contracts, etc.)?
Yes. Use groups to define access for each module.
Why can’t a new user see any data?
New users must be added to a group before they can access any records.
Summary
RBAC helps you control access in a simple and structured way:
- Roles define what users can do
- Groups define what users can access
- Roles always take precedence over group permissions
This ensures the right people have the right level of access at all times.
