Roles in the platform are organized hierarchically across Workspace, Application and Table levels. Each role determines what actions users can perform and where their access applies. Here's an explanation of how roles work at each level, along with their permissions.
1. Workspace-Level Roles
Roles at the workspace level apply broadly to all applications and tables within the workspace, providing default access unless overridden at the application or table level. The workspace creator is automatically assigned the Admin role, with the ability to manage members, roles, and permissions across the workspace. Workspace roles include Admin, Builder, and No Role, with "No Role" reserved for users who don’t require workspace-wide access but are assigned specific permissions at the application or table level.
Workspace-Level Permissions:
Actions | Admin | Builder | No Role |
Invite Members | ✓ |
|
|
Manage Roles | ✓ |
|
|
Remove Users | ✓ |
|
|
View Workspace Contents (Application, Tables, Collaborative Views) | ✓ | ✓ |
|
Full Workspace Management (Rename, Leave, Delete) | ✓ |
|
|
Full Application Configurations (Add, Edit, Delete) | ✓ | ✓ |
|
Full Tables Configurations (Add, Edit, Delete) | ✓ | ✓ |
|
Full Columns Configurations (Add, Edit, Delete) | ✓ | ✓ |
|
Full Collaborative Views Configurations | ✓ | ✓ |
|
Full Data Configurations (Add, Edit, Import, Export, Delete) | ✓ | ✓ |
|
Add Comments | ✓ | ✓ |
|
Add Mentions | ✓ | ✓ |
|
Add Personal Views | ✓ | ✓ |
|
View Trash on (Workspace, Applications, Tables) Levels | ✓ | ✓ |
|
Restore Data on (Workspace, Applications, Tables) Levels | ✓ | ✓ |
|
Backup Data on Application Level | ✓ |
|
|
Example: An Admin can invite a user to the workspace and assign them the Builder role, which allows them to create applications and manage tables.
⚠️ Roles assigned at the application and table levels always override the workspace-level permissions. This means that even if a user has limited access at the workspace level, the roles set at the application or table level will determine what they can do within specific applications or tables. This ensures more granular control over data and actions within those applications and tables.
2. Application Level Roles
Roles at the application level define what users can do within a specific application and take precedence over workspace-level roles. For example, a user assigned as a Builder at the application level can manage tables and configurations within that application, even if their workspace role is No Role.
Application-Level Permissions:
Actions | Admin | Builder | Editor | Commenter | Viewer | No Role |
Invite Members to Application | ✓ |
|
|
|
|
|
Manage Roles on Application | ✓ |
|
|
|
|
|
Remove Users from Application | ✓ |
|
|
|
|
|
View Application Contents (Tables, Collaborative Views) | ✓ | ✓ | ✓ | ✓ | ✓ |
|
Full Application Configurations (Add, Edit, Delete) | ✓ | ✓ |
|
|
|
|
Full Tables Configurations (Add, Edit, Delete) | ✓ | ✓ |
|
|
|
|
Full Columns Configurations (Add, Edit, Delete) | ✓ | ✓ |
|
|
|
|
Full Data Configurations (Add, Edit, Import, Export, Delete) | ✓ | ✓ | ✓ |
|
|
|
Add Comments | ✓ | ✓ | ✓ | ✓ |
|
|
Add Mentions | ✓ | ✓ | ✓ | ✓ |
|
|
Full Collaborative Views Configurations | ✓ | ✓ |
|
|
|
|
Add Personal Views | ✓ | ✓ | ✓ | ✓ | ✓ |
|
View Trash for Application and Tables | ✓ | ✓ | ✓ | ✓ | ✓ |
|
Restore Data for Application and Tables | ✓ | ✓ |
|
|
|
|
Backup Data on Application Level | ✓ |
|
|
|
|
|
Example: A user with the no-role at the workspace level can be assigned as Builder for the "Project Management" application, enabling them to create and manage tables within that application.
⚠️ Invitations at the application level are restricted to existing users within the workspace. New users cannot be invited directly to an application; they must first be added to the workspace by a workspace admin. Once a user is part of the workspace, their access to specific applications can be managed through application-level roles
3. Table-Level Roles
Roles at the table level define what users can do within a specific table and take precedence over workspace-level and application-level roles. For example, a user assigned as a Builder at the table level can manage columns, data, and configurations within that table, even if their workspace role is more limited.
Actions | Admin | Builder | Editor | Commenter | Viewer | No Role |
Invite Members to Table | ✓ |
|
|
|
|
|
Manage Roles on Table | ✓ |
|
|
|
|
|
Remove Users from Table | ✓ |
|
|
|
|
|
View Table Contents (Collaborative Views) | ✓ | ✓ | ✓ | ✓ | ✓ |
|
Full Table Configurations (Add, Edit, Delete) | ✓ | ✓ |
|
|
|
|
Full Columns Configurations (Add, Edit, Delete) | ✓ | ✓ |
|
|
|
|
Full Data Configurations (Add, Edit, Import, Export, Delete) | ✓ | ✓ | ✓ |
|
|
|
Add Comments | ✓ | ✓ | ✓ | ✓ |
|
|
Add Mentions | ✓ | ✓ | ✓ | ✓ |
|
|
Full Collaborative Views Configurations (Add, Edit, Share, Delete) | ✓ | ✓ |
|
|
|
|
Add Personal Views | ✓ | ✓ | ✓ | ✓ | ✓ |
|
View Trash for Table | ✓ | ✓ | ✓ | ✓ | ✓ |
|
Restore Data for Table | ✓ | ✓ |
|
|
|
|
⚠️ Invitations at the table level are restricted to existing users within the workspace. New users cannot be invited directly to a table; they must first be added to the workspace by a workspace admin. Once a user is part of the workspace, their access to specific tables can be managed through table-level roles.