Role Levels and Permissions

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:

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.

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:

• 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.

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.