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**:

1. **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**.

2. **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**.

3. **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.

4. **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:

1. **Teams**: Assigning roles to teams allows you to manage access collectively, ensuring that everyone in a team has the same permissions.

2. **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 ha 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**:

1. **Workspace Role**: Sarah is a Builder at the workspace level, giving her permissions to create and manage applications across the workspace.

2. **Application Role**: In the "Project Management" application, her Admin role overrides her Builder role, granting her full control over this specific application.

3. **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**

1. **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.

2. **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.

3. **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.

4. **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.

5. **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.

##