---
title: "Module-Level Role-Based Access Control (RBAC)"
slug: "module-level-role-based-access-control-rbac"
updated: 2026-10-02T17:05:30Z
published: 2026-10-02T17:05:30Z
canonical: "docs.unqork.io/module-level-role-based-access-control-rbac"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.unqork.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Module-Level Role-Based Access Control (RBAC)

Module-level RBAC provides default permissions for all components in a module. It sits between environment-level role defaults and component-level permissions. Creators use it to set efficient security across entire modules.

Module-level RBAC controls end-user access to modules by setting default permissions for each Express Role at the module level.

## How Module-Level RBAC Works

Module-level RBAC behavior differs depending on whether the **Customize RBAC for This Module** toggle is on or off. The system computes effective permissions from the inheritance chain.

### When RBAC Is Enabled

When **Customize RBAC for This Module** is enabled, the system activates the following granular permission controls:

- Explicit permissions can be set for each Express Role.
- Components **inherit** the module's permission settings by default.
- Components can **override** module permissions individually.
- The system computes **effective permissions** by evaluating the permission hierarchy.

**Permission Hierarchy**:

```
none (lowest) < read < write (highest)
```

When an end-user has multiple roles, the **highest permission level** wins.

### When RBAC Is Disabled

When **Customize RBAC for This Module** is **OFF**, the following occurs:

- The permissions table is disabled.
- End-users with the **NoAccess** role are restricted.
- Anonymous access is automatically disabled.
- **All other authenticated roles automatically get Write access** to the module and its components.
- Component-level permissions are ignored.

**Critical Distinction**: Disabling RBAC grants Write access to all authenticated roles except NoAccess, instead of requiring explicit permission grants. Anonymous access is disabled.

### Effective Permissions

**Effective permissions** are the final computed permissions after evaluating the entire inheritance chain.

The system tracks the following:

- **Permission value**: The actual permission level (none, read, write).
- **Source**: Where the permission came from. Options include:
  - **Role Defaults**: Inherited from the Express Role's default permission.
  - **Module**: Set explicitly at the module level.

**Evaluation Order**:

1. **Admin roles**: Always get **Write** permission.
2. **NoAccess role**: Always gets **None** permission.
3. **Other roles** (when **Customize RBAC for This Module** is enabled):

When **Customize RBAC for This Module** is disabled, all other authenticated roles automatically get **Write** permission.
  - If the component has an explicit permission set, the component permission applies.
  - If the module has an explicit permission set, the module permission applies.
  - If the role has a default permission, the role default applies.
  - If none of the above are set, **None** applies.

## Module RBAC Settings

To access the module settings panel, open the module in **Module Builder** and select **Settings** from the ![EllipsisVertical](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/api_upload_20261002_170528_81f29318e5f04c2bb4f2c5f609c3d97c.svg?sv=2026-02-06&spr=https&st=2026-11-07T17%3A57%3A41Z&se=2026-11-07T18%3A57%3A41Z&sr=c&sp=r&sig=zTskOG4QAEEK7nAylWezYQ8xYt9Tf6q4X2%2B4EmPegWw%3D) (**ellipsis**) **Definition** menu. Then select **User Permissions** from the left sidebar.

The following settings appear in the **User Permissions** section.

### Customize RBAC for This Module

**What it does**:

- **When ENABLED**, the following occurs:
  - Activates the permissions table.
  - Explicit role-to-permission mappings become active.
  - Components can have field-level permissions.
  - End-users see the module based on their explicit permissions.
- **When DISABLED**, the following occurs:
  - Permissions table is disabled.
  - The NoAccess role is restricted.
  - Anonymous access is disabled.
  - All other authenticated roles get Write access automatically.
  - Component permissions are ignored.

**Storage**: Stored as `module.settings.enableRbac` (boolean)

### Allow Access to Anonymous Users

**What it does**:

- Lets unauthenticated end-users access the module.
- Only works when **Customize RBAC for This Module** is enabled.
- When **ON**, this setting lets Creators set specific permissions for the Anonymous role.

**Restrictions**:

- Automatically disabled when **Customize RBAC for This Module** is set to **OFF**.
- Cannot be enabled without RBAC customization.

**Storage**: Stored as `module.settings.enableAnonymous` (boolean)

### Permissions Table

The permissions table displays all Express Roles and their permission settings for the module.

**Columns**:

| Column | Description |
| --- | --- |
| **Role (Express)** | Express Role name, hierarchically indented to display parent/child relationships. |
| **Permission** | Drop-down selector to set the permission for this role. |
| **Effective Permission** | Read-only display of the computed permission after inheritance. |
| **Inherited From** | Shows the source: **Role Defaults** (inherited from the role default) or **Module** (set explicitly at this module). |

**Permission Options**:

At the module level, the following options are available:

- **Inherit**: Use the role's default permission from environment settings.
- **No Access**: Block access completely. End-users cannot see or access the module.
- **Read-Only**: End-users can view data but cannot edit it.
- **Write**: End-users have full access to view and edit data.

> [!NOTE]
> The **Obfuscate** option is available at the component level, not at the module level.

**Disabled Rows**:

- **Locked modules**: All selectors are disabled.

## Enabling Module-Level RBAC

1. Open the module in **Module Builder**.
2. From the ![EllipsisVertical](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/api_upload_20261002_170528_81f29318e5f04c2bb4f2c5f609c3d97c.svg?sv=2026-02-06&spr=https&st=2026-11-07T17%3A57%3A41Z&se=2026-11-07T18%3A57%3A41Z&sr=c&sp=r&sig=zTskOG4QAEEK7nAylWezYQ8xYt9Tf6q4X2%2B4EmPegWw%3D) (**ellipsis**) **Definition** menu, select **Settings**.
3. In the left sidebar, select **User Permissions**.
4. Toggle **Customize RBAC for This Module** to **ON**. The permissions table becomes active.
5. For each Express Role, select a permission from the **Permission** drop-down. Options include:
  - **Inherit**: Use the role's default permission.
  - **No Access**: Block access completely.
  - **Read-Only**: View.
  - **Write**: Full access.
6. Review the **Effective Permission** and **Inherited From** columns to verify the computed result.
7. Click **Save**.

To grant unauthenticated access, toggle **Allow Access to Anonymous Users** to **ON** and set a permission for the **Anonymous** role, typically **Read-Only** or **No Access**.

## Permission Inheritance Examples

The following examples show how permission levels are computed across different configurations of RBAC, role defaults, and module overrides.

### Example 1: Basic Inheritance

**Environment Setup**:

- **Role**: Standard User
- **Role Default Permission**: Read

**Module Configuration**:

- **Customize RBAC**: OFF

**Result**:

- Standard User gets **Write** access (disabling RBAC grants Write to all authenticated roles except NoAccess).

### Example 2: Module Override

**Environment Setup**:

- **Role**: Standard User
- **Role Default Permission**: Read

**Module Configuration**:

- **Customize RBAC**: ON
- **Standard User Permission**: Write

**Result**:

- Standard User gets **Write** access (module overrides role default).

### Example 3: Multiple Roles

**Environment Setup**:

- **User**: Jane
- **Roles**: Viewer (default: Read), Editor (default: Write)

**Module Configuration**:

- **Customize RBAC**: ON
- **Viewer Permission**: Read
- **Editor Permission**: Write

**Result**:

- Jane gets **Write** access (highest permission from all roles).

### Example 4: Anonymous Access

**Environment Setup**:

- **Role**: Anonymous (default: None)

**Module Configuration**:

- **Customize RBAC**: ON
- **Allow Anonymous Access**: ON
- **Anonymous Permission**: Read-Only

**Result**:

- Unauthenticated end-users can view the module but cannot edit.

## When to Use Module-Level RBAC

Module-level RBAC is most effective when access rules are consistent across most or all components in a module. It also applies when a secure default must be established before individual fields are tuned. The following scenarios illustrate where this approach adds the most value.

### All Components Should Have the Same Rules

If every field in a module should have identical access rules for each role, set it at the module level. This approach avoids configuring each component individually. For example, an employee directory module where all fields (name, email, phone) should be read-only for Standard Users and writable for HR Managers.

### Establishing a Security Baseline

Set conservative defaults at the module level, then override specific components that need different permissions. For example, set the module to **Read-Only** for most roles, but mark a **Comments** field as **Write** for all authenticated end-users.

### Building Public-Facing Modules

Enable Anonymous Access and set appropriate permissions for unauthenticated end-users. For example, a product inquiry form where anonymous end-users can submit data. Form fields are set to **Write**, but data tables are set to **No Access** so submissions cannot be viewed.

### Minimal Component Overrides

If a few fields need special permissions, it is more efficient to set module defaults and override exceptions. For example, a claims form where most fields follow standard role permissions, but the SSN field must be obfuscated for certain roles.

## Best Practices

The following practices reduce permission complexity and prevent unintended access.

### 1. Begin with Module Defaults

- Configure module-level permissions first.
- Set conservative defaults (Read-Only or No Access).
- Override at the component level for exceptions.

### 2. Test with Different Roles

- Create test end-user accounts with different role assignments to test each role.
- Verify that effective permissions match expectations.
- Check the **Inherited From** column to understand permission sources.

### 3. Use Inherit When Possible

- Set roles to **Inherit** if the environment default is correct.
- Avoid unnecessary overrides that complicate maintenance.
- Override when different behavior is needed.

### 4. Document Permission Decisions

- Add comments in Module Builder describing why certain roles have specific permissions.
- Maintain a permission matrix document for complex modules.
- Share with stakeholders before deployment.

### 5. Limit Anonymous Access

- Only enable anonymous access when absolutely necessary.
- Set Anonymous to Read-Only or No Access by default.
- Never grant Write access to Anonymous end-users for sensitive data.

### 6. Review Effective Permissions

- Always check the **Effective Permission** column after making changes.
- Verify that role hierarchy does not create unintended permissions.
- Use the lowest necessary permission level.

## Common Patterns

The following patterns cover the most frequent module RBAC configurations.

### Pattern 1: Public Submission Form

**Use Case**: Anonymous end-users can submit data, but cannot view other submissions.

**Configuration**:

- **Customize RBAC**: ON
- **Allow Anonymous Access**: ON
- **Anonymous Permission:** Write (for form fields)
- **Component overrides**: Set data tables to **No Access** for Anonymous

### Pattern 2: Read-Only Reference Module

**Use Case**: Most end-users can view data; administrators can edit.

**Configuration**:

- **Customize RBAC**: ON
- **Standard User Permission:** Read-Only
- **Administrator Permission:** Write

### Pattern 3: Progressive Disclosure

**Use Case**: Different roles see different levels of detail.

**Configuration**:

- **Customize RBAC**: ON
- **Basic User Permission:** Read-Only
- **Advanced User Permission:** Write
- **Component overrides**: Hide sensitive fields from Basic User (No Access), display for Advanced User

### Pattern 4: Workflow with Stages

**Use Case**: End-users can edit their own submissions, managers can edit all.

**Configuration**:

- **Customize RBAC**: ON
- **Submitter Permission:** Write
- **Manager Permission:** Write
- Use Groups to control data access between submitters and managers.

**Changelog**

| Date | Change |
| --- | --- |
| 2026-07-15 | Initial publication - full accuracy sweep and editorial pass. |

RBAC (Role-Based Access Control) is a method to control system access for authorized users. The role in RBAC refers to the levels of access employees have to a network.

Also known as Unqork Users, or Designer Users; is anyone who is inside the Unqork platform.

End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product.

The Unqork front-end application framework that delivers Creator-built applications to end-users. Express is the layer end-users interact with—the published forms, screens, and navigation built in the Module Builder. Express is distinct from Express View, which is a Creator-facing preview tool in the IDE.

End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product.