Roles are organized hierarchically across three levels: Workspace, Application, and Table. This structure ensures that access and permissions become more specific as you move from the workspace to individual tables. Access Levels include roles assigned to Teams or Individual Members, where member roles always override team roles to provide precise control.
Hierarchy Overview:
Workspace Level:
Roles at this level apply broadly across the entire workspace.
Example: Assigning someone as an "Admin" at the workspace level gives them control over all applications and tables within the workspace.
Application Level:
Roles here apply to specific applications within the workspace.
Example: A user can be a "Builder" for one application but a "Viewer" for another, depending on their assigned role.
Table Level:
This is the most specific level, where roles are assigned to individual tables.
Example: A user could have "Editor" access to a specific table while having "No Access" to other tables in the same application.
View Level (Share ONLY):
Different View Types can be shared without inviting members.
Example: Sharing a Form View helps to collect well-structured answers across organizations.
How It Works:
More Specific Levels Take Priority: A table-level role overrides an application-level role, and an application-level role overrides a workspace-level role.
Member Roles Overrule Team Roles: If a member has an explicitly assigned role at any level (workspace, application, or table), that role takes precedence over their team’s default role.
Flexible Assignments: This hierarchy allows for detailed control, so users can have broader access at higher levels and more restricted or specialized access at lower levels.
By starting at the workspace level and refining permissions down to individual tables, you can ensure the right people have access to the right data and tools.
Access Levels: Teams and Members
Roles can be assigned to both Teams and Individual Members, offering flexible access control:
Teams: Assigning roles to teams allows you to manage access collectively, ensuring that everyone in a team has the same permissions.
Members: Assigning roles to individual members ensures more granular control, overriding the default roles assigned to their teams.
Member Roles Always Override Team Roles: If a member has an explicitly assigned role at any level (workspace, application, or table), that role takes precedence over their team’s default role.
Example of Role Hierarchy
Imagine a workspace managing a company's projects. Here's how the role hierarchy works across Workspace, Application, and Table levels.
Scenario:
User: Sarah
Workspace Role: Builder (she can configure applications and tables across the workspace).
Application Role: Admin for the "Project Management" application (she has full control over this application).
Table Role: No Role for the "Risks" table within the "Project Management" application (she cannot access or edit this specific table).
How It Works:
Workspace Role: Sarah is a Builder at the workspace level, giving her permissions to create and manage applications across the workspace.
Application Role: In the "Project Management" application, her Admin role overrides her Builder role, granting her full control over this specific application.
Table Role: On the "Risk" table, her No Role status takes precedence, meaning she cannot access or edit this table, even with her Admin permissions at the application level.
This example highlights how DataLexing prioritizes the most specific roles, ensuring granular control and secure management of access.
Best Practices for Managing Role Hierarchy & Access Levels
Start with Application-Level Roles
Assign roles at the application level to define access for specific areas of your workspace.Example: Assign "Builder" to a user for the "Project Management" application so they can create and manage tables within that application.
Use Table-Level Roles for Granular Access
Assign roles at the table level to control access and actions for individual tables.Example: Assign "Editor" to a user on the "Risk" table to allow data editing without granting access to other tables.
Understand Role Priorities
Roles at lower levels (Workspace > Application > Table) take precedence over higher-level roles.
Member roles always override team roles, ensuring individual permissions are respected.
Manage Team Roles Effectively
Use team roles for simplicity and consistency but adjust member roles where exceptions are needed.Assign team roles for applications and tables to manage collective access easily.
Adjust Roles as Needed
Review and update roles regularly to match project responsibilities.Example: Temporarily assign a "Builder" role to a user for specific tasks and revert to "No Role" when access is no longer needed.
By following this structure, you can efficiently manage roles while ensuring secure and streamlined collaboration.