---
title: "Express Role-Based Access Control (RBAC) Overview"
slug: "express-role-based-access-control-rbac-overview"
updated: 2026-10-02T17:05:25Z
published: 2026-10-02T17:05:25Z
canonical: "docs.unqork.io/express-role-based-access-control-rbac-overview"
---

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

# Express Role-Based Access Control (RBAC) Overview

Role-Based Access Control (RBAC) in Unqork lets Creators control who can access applications and what end-users can see or do in them. RBAC operates at three levels: **Environment**, **Module**, and **Component**. Each serves a distinct role in the permission hierarchy.

## The Three Levels of RBAC

Unqork's Express RBAC operates at the following three distinct levels, each serving a different purpose:

| Level | Scope | Controls | Set By |
| --- | --- | --- | --- |
| **Environment** | Platform-wide | Who can access applications | Environment Administrator |
| **Module** | Module/workflow | Default permissions for all fields in a module | Module Builder settings |
| **Component** | Individual fields | Field-specific read/write/obfuscate rules | Component configuration panel |

**Permission Hierarchy**: Component-level permissions override Module defaults, which in turn inherit from Environment role settings.

## Level 1: Environment-Level Permissions

Environment-level RBAC determines **who can log in** and **what their default permissions are** across all applications in an environment. This is managed through **Express Roles** and **Groups**.

### Express Roles

**Express Roles** are platform-wide end-user roles that define baseline access to applications. They serve as the foundation for all permission decisions.

Express Roles are configured in the <idelink href="/settings/express-role-administration" breadcrumb="Administration > Express Permissions > Express Role Administration">Express Role Administration</idelink> page.

**Key Characteristics** include the following:

- **Default Permission**: Each role has a baseline permission level (`none`, `read`, or `write`). This permission applies to all modules unless overridden at the module or component level.
- **Role Hierarchy**: Roles can inherit from parent roles, creating a permission tree (for example, "Administrator" inherits all permissions from "Standard User").
- **Super User Flags**: Special flags grant the following elevated privileges:
  - **Designer Access Super User**: Lets Creators create and edit applications in Module Builder.
  - **Submission Access Super User**: Lets end-users view all submissions regardless of RBAC rules.

**Common Role Examples** include the following:

| Role | Typical Default Permission | Use Case |
| --- | --- | --- |
| Administrator | Write | Full access to all applications and data |
| Standard User | Read | Access to view and edit specific workflows |
| Viewer | Read | Read-only access for reporting and auditing |
| Guest | None | Restricted access requiring explicit grants |

End-users are assigned or more Express Roles by an Environment Administrator. When an end-user has multiple roles, the **highest permission level** from any role applies.

### Groups

**Groups** are collections of end-users that can be assigned roles collectively. Instead of assigning roles to individual end-users, roles can be assigned to a group and all members inherit those roles.

Groups are configured in the <idelink href="/settings/express-group-administration" breadcrumb="Administration > Express Permissions > Express Group Administration">Express Group Administration</idelink> page.

**Key Characteristics** include the following:

- **Group Membership**: End-users can belong to multiple groups (for example, "Finance Team", "Regional Managers").
- **Role Assignment**: Roles can be assigned to groups, and all group members receive those roles.
- **Centralized Management**: Updating a group's roles automatically updates permissions for all members.

**Common Group Examples** include the following:

| Group | Assigned Roles | Use Case |
| --- | --- | --- |
| Claims Adjusters | Claims Adjuster, Standard User | All adjusters get the same permissions |
| HR Managers | HR Manager, Administrator | HR management team with elevated access |
| External Auditors | Viewer | Read-only access for compliance reviews |

Roles and groups work together in the following way:

1. **Groups are assigned Express Roles**: A group like "Finance Team" might be assigned the "Finance User" role.
2. **End-users join Groups**: When an end-user is added to "Finance Team", they automatically receive the "Finance User" role.
3. **Permissions cascade**: The end-user's effective permissions are the **highest permission** from all roles across all groups they belong to, plus any individually assigned roles.

Consider the following example:

- **End-user**: Sarah
- **Groups**: "Finance Team" (assigned role: "Finance User" with `read` default), "Approvers" (assigned role: "Approver" with `write` default)
- **Individual Roles**: None
- **Effective Permission**: `Write` (highest of `read` and `write`)

Environment Administrators configure Express Roles and Groups through the **Express Role Administration** and **Express Group Administration** pages (Administration > Express Permissions). Application builders reference these roles when setting module and component permissions, but do not create or assign them.

### Application Entry-Point RBAC

In addition to environment-wide Express Roles, Administrators can assign a specific role to an individual end-user for a specific application. The assigned role overrides that end-user's default Express Role, but for that application's **entry-point module**.

> [!CAUTION]
> Application Entry-Point RBAC does not protect sub-modules. End-users can navigate directly to a sub-module URL and bypass this restriction. To restrict access to sub-modules, configure RBAC at the [module level](/unqorkai/docs/module-level-role-based-access-control-rbac) or [component level](/unqorkai/docs/component-level-role-based-access-control-rbac) for each sub-module.

Configure Application Entry-Point roles in [Express User Administration](/unqorkai/docs/express-user-administration). For full details, see [Environment-Level RBAC](/unqorkai/docs/environment-level-role-based-access-control-rbac-unqork).

### When to Use Environment-Level Permissions

Use environment-level permissions in the following cases:

- Establishing default permissions across all applications in the environment.
- Managing end-user access centrally instead of on a per-application basis.
- Creating a role hierarchy that reflects the organizational structure (for example, Manager inherits from Employee).

## Level 2: Module-Level Permissions

Module-level RBAC sets **default permissions** for all components in a module. This is the most efficient way to secure entire workflows.

Module-level RBAC uses the following four permission levels:

| Permission | User Can See Field? | User Can Edit Field? | Data Submitted? | Display Behavior |
| --- | --- | --- | --- | --- |
| **Write** | Yes | Yes | Yes | Fully editable input |
| **Read** | Yes | No | Yes | Read-only (Display as Text) |
| **None** | No | No | No | Field hidden entirely |

> [!NOTE]
> Obfuscate is **not available** at the module level; it is a component-only permission.

When an end-user has multiple roles, the **highest permission level** from any role applies.

### Enabling RBAC on a Module

**Step 1: Open Module Permissions**

1. Open the module in **Module Builder**.
2. Click the **Module Settings** tab.
3. Navigate to the **Module Permissions** section.

**Step 2: Customize RBAC**

- Toggle **Customize RBAC for This Module** to **ON**.
- When set to **ON**, this toggle makes all components inherit module-level permissions.

**Step 3: Configure Role Permissions**

The **Permissions** table displays the following four columns:

- **Role (Express)**: Each Express Role in the environment, shown in a hierarchy if roles have parent roles.
- **Permission**: Drop-down to select the permission level for this role (Write, Read, or None).
- **Effective Permission**: The computed permission after evaluating role defaults and inheritance.
- **Inherited From**: Displays where the permission comes from (for example, "Role Defaults" if using the role's default permission).

Set the default permission level for each role using the **Permission** drop-down.

Click **Save**.

**Step 4: (Optional) Allow Anonymous Access**

- Toggle **Allow Access to Anonymous Users** to **ON** if unauthenticated end-users should access this module.
- When set to **ON**, this toggle lets Creators configure specific permissions for the **Anonymous** role in the permissions table.

> [!NOTE]
> This toggle displays when **Customize RBAC for This Module** is enabled.

### When to Use Module-Level Permissions

Use module-level permissions in the following cases:

- All fields in the module should have the same access rules.
- Creators need a quick, module-wide security baseline.
- Creators plan to override a few specific fields at the component level.

## Level 3: Component-Level Permissions

Component-level RBAC provides **fine-grained control** over individual fields. These permissions **override** module defaults.

Component-level RBAC uses the following five permission levels:

| Permission | User Can See Field? | User Can Edit Field? | Data Submitted? | Display Behavior |
| --- | --- | --- | --- | --- |
| **Write** | Yes | Yes | Yes | Fully editable input |
| **Read** | Yes | No | Yes | Read-only (Display as Text) |
| **Obfuscate** | Yes (masked) | No | Yes (as `********`) | Displays `********` instead of value |
| **None** | No | No | No | Field hidden entirely |
| **Inherit** | Depends on parent | Depends on parent | Depends on parent | Uses permission from parent component, module, or role default |

**Permission Hierarchy**: `Write > Read > Obfuscate > None`

**Inherit** is a special value that uses the parent component's permission or the role's default permission. The component schema stores the value `"inherit"` for this permission.

When an end-user has multiple roles, the **highest permission level** from any role applies.

### Configuring Component Permissions

**Step 1: Select the Component**

1. In **Module Builder**, click the component to configure.
2. The configuration panel opens on the right.

**Step 2: Open the Permissions Tab**

- Navigate to the **Permissions** tab in the component configuration panel.

**Step 3: Set Role-Specific Permissions**

The **Permissions** table displays the following four columns:

- **Role (Express)**: Each Express Role in the environment.
- **Permission**: Drop-down to select the permission level (Inherit, None, Read, Write, or Obfuscate).
- **Effective Permission**: The computed permission for this component after evaluating inheritance.
- **Inherited From**: Displays the source: "Role Defaults" (inherited from the role default) or "Component: {type}" (inherited from an ancestor component).

Set the permission level for each role using the **Permission** drop-down.

Click **Done** to save.

### When to Use Component-Level Permissions

Use component-level permissions in the following cases:

- Certain fields contain sensitive data (PII, financial info).
- Different roles need different access to specific fields.
- Creators want to display a field but hide its value (obfuscate).

## How Permissions Are Resolved

When an end-user opens a module, Unqork evaluates permissions in the following order:

1. **End-user's Express Roles**: Determines which roles apply to the end-user.
2. **Highest Role Permission**: If an end-user has multiple roles, the highest permission wins.
3. **Component Override Check**: If the component has explicit permissions set, they override module defaults.
4. **Module Default**: If no component override exists, the module's permission for that role applies.
5. **Role Default**: If neither component nor module sets a permission, the role's default permission applies.

Consider the following example:

- **End-user**: Jane (Roles: `Administrator`, `Claims Reviewer`).
- **Module Default**: `Administrator: Write`, `Claims Reviewer: Read`.
- **Component Override (SSN field)**: `Administrator: Write`, `Claims Reviewer: Obfuscate`.

The result is as follows:

- On most fields: Jane has `Write` (highest of `Write` vs. `Read`).
- On SSN field: Jane has `Write` (component override applies, highest of `Write` vs. `Obfuscate`).

## Testing Your Permissions

Testing ensures that effective permissions match the intended design across all roles. Start with the most restricted roles and work up.

### Testing Different Roles

To test how the module displays to different roles, complete the following steps:

1. Create test accounts with different role assignments.
2. Log in as each test account to verify the module displays correctly for that role.
3. Verify that fields with different permissions (Read, Write, Obfuscate, None) behave as expected.

> [!TIP]
> Test every role to ensure fields display, hide, and behave as expected. Pay special attention to obfuscated fields to confirm values are masked correctly.

### Common Issues

**Issue**: All fields are visible to all end-users.

Apply the following solutions:

- Verify **Customize RBAC for This Module** is toggled **ON** in the **User Permissions** section under **Settings**.
- Confirm that module-level or component-level permissions are configured.

**Issue**: A field is hidden when it should be visible.

Apply the following solutions:

- Check the component's **Permissions** tab; it might have an explicit `None` permission overriding the module default.
- Verify the end-user has been assigned the correct Express Role in User Management.

**Issue**: End-user can see obfuscated data in the browser console.

Apply the following solution:

- Obfuscation replaces the actual value with `********` **server-side** before sending data to the client. The end-user cannot retrieve the original value, even through DevTools. If the real value displays in the browser console, verify that the component permission is set to **Obfuscate** (not just Read).

## Best Practices

The following practices help maintain a secure, maintainable permission structure across modules and roles.

### 1. Begin with Module Defaults

- Set module-level permissions first to establish a baseline.
- Override at the component level for exceptions.

### 2. Use the Principle of Least Privilege

- Grant the minimum permission required for each role.
- Default to `None` or `Read` for most users; grant `Write` when necessary.

### 3. Document Role Definitions

- Maintain a role matrix documenting which roles can access which modules and fields.
- Share this with stakeholders before building the application.

### 4. Test with Real User Accounts

- Preview mode is helpful, but create test accounts with actual role assignments.
- Test end-to-end workflows to catch permission gaps.

### 5. Avoid Over-Obfuscating

- Obfuscation is useful for sensitive data, but overuse degrades end-user experience.
- If a field should be hidden, use `None` instead of `Obfuscate`.

### 6. Audit Permissions Regularly

- Review permissions when roles change or new regulations are introduced.
- If available in the environment, use the **Permissions Summary** report to spot gaps.

**Changelog**

| Date | Change |
| --- | --- |
| 2026-07-29 | Added Application Entry-Point RBAC subsection with security limitation callout (EN-7957). |
| 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.

Scope is a tool that limits an application's access to a user's account. An application can request one or more scopes, this information is then presented to the user in the consent screen, and the access token issued to the application will be limited to the scopes granted.

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.

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.

In Unqork an application is a program used to perform specific tasks. An application can be one of two types: workflow or module.

A URL (uniform resource locator) is a unique identifier used to locate a resource on the internet. Also known as a web address.

Schema is a declarative language that defines the structure, content, and constraints of the data.

Personal Identifiable Information (PII) is any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means.

The DevTools Console helps you securely store, build, test, and deploy your software.