---
title: "Environment-Level Role-Based Access Control (RBAC)"
slug: "environment-level-role-based-access-control-rbac-unqork"
tags: ["rbac", "security"]
updated: 2026-10-02T16:52:05Z
published: 2026-10-02T16:52:05Z
canonical: "docs.unqork.io/environment-level-role-based-access-control-rbac-unqork"
---
> ## 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.
# Environment-Level Role-Based Access Control (RBAC)
Environment-level RBAC controls who accesses Express applications (the end-user facing modules and workflows built in Unqork) and what their baseline permissions are. This is separate from Creator roles, which control access to Module Builder. This article covers managing **Express Roles** and **Express Groups**.
Environment-level RBAC consists of the following core concepts:
| Concept | Purpose | Managed By |
| --- | --- | --- |
| **Express Roles** | Define baseline permissions and end-user capabilities across all applications | Environment Administrator |
| **Express Groups** | Control data access rules between end-users based on role hierarchy | Environment Administrator |
| **Application Entry-Point RBAC** | Override an end-user's Express Role for a specific application's entry-point module | Environment Administrator |
**Permission Requirement**: Managing roles and groups requires Creator permissions to access the **Express Role Administration** and **Express Group Administration** pages.
## Express Roles
Express Roles are platform-wide roles that define what end-users can see and do when accessing applications. These control Express application permissions, not Module Builder access.
### Role Properties
Each Express Role has the following properties:
| Property | Description | Example |
| --- | --- | --- |
| **Name** | Unique identifier for the role (alphanumeric + hyphens, cannot begin with hyphen) | `claims-adjuster` |
| **Description** | Text explanation of the role's purpose | "Claims adjusters who process insurance claims" |
| **Parent Role** | Role from which this role inherits permissions (optional) | `standard-user` |
| **Default Permission** | Baseline permission level applied to all modules | No Access, Read-Only, or Write |
| **Full Submission Access** | If enabled, end-users can view all submissions regardless of RBAC rules | Checkbox (admin) |
| **Designer Access** | If enabled, end-users can create and edit applications in Module Builder | Checkbox (admin) |
| **Groups** | Groups this role belongs to | `finance-team`, `approvers` |
### Role Hierarchy
Roles can inherit from parent roles, creating a permission tree:
- A child role inherits the parent's default permission as a baseline.
- Child roles can have more restrictive permissions than their parent.
- Role hierarchy is visualized in the **View Role Hierarchy** dialog.
- Parent roles are bolded; children are indented.
**Example Hierarchy**:
```
Administrator (Write)
└── Standard User (Read)
└── Claims Adjuster (Write)
└── Claims Reviewer (Read)
└── Viewer (Read)
└── External Auditor (Read)
```
### Default Roles (Protected)
The following roles are system defaults and **cannot be deleted**. Their parent, default permission, and super user flags are locked:
- **Administrator**: Full access to all applications and data.
- **Authenticated**: Base role for logged-in end-users.
- **NoAccess**: No permissions (used to explicitly deny access).
- **Anonymous**: Unauthenticated end-users (if anonymous access is enabled).
## Managing Express Roles
### Viewing Existing Roles
Navigate to Express Role Administration in the UnqorkAI platform.
1. The role list displays:
- **Role**: The unique role identifier.
- **Description**: Purpose of the role.
- **Permission**: Badge showing permission level:
- Red: No Access.
- Amber: Read-Only.
- Green: Write.
- **Actions**: Drop-down with Edit and Delete options.
2. Use the **search bar** to filter roles by name or description.
3. Pagination controls display at the bottom (default: 10 roles per page).
### Creating a Role
Navigate to Express Role Administration.
1. Click **Add Role**.
2. Fill in the form:
**Role Name** (required)
**Role Description** (optional)
**Select Parent** (optional)
**Select Default Permission** (required)
**Full Submission Access** (optional)
**Designer Access (Super-user)** (optional)
**Add to Group(s)** (optional)
- Alphanumeric characters and hyphens.
- Cannot begin with a hyphen.
- Maximum 255 characters.
- Must be unique.
- Explain the role's purpose and who should be assigned to it.
- Select a parent role from the drop-down.
- This role inherits the parent's baseline permissions.
- Select **No Access**, **Read-Only**, or **Write**.
- This permission applies to all modules unless overridden at the module or component level.
- When **Full Submission Access** is enabled, this field is automatically set to Write and cannot be changed.
- When checked, end-users can view all submissions regardless of RBAC rules.
- An alert warns that this setting grants unrestricted read/write access to all submissions, overriding role hierarchy, group membership, and field-level permissions. Use sparingly, typically for administrators and auditors.
- When checked, end-users can create and edit applications in Module Builder.
- Only visible in edit mode. A new role cannot be given Designer Access at creation.
- Deprecated. Administrators can retire the option environment-wide from [Environment Administration](/unqorkai/docs/environment-administration#designer-access-deprecated).
- Select or more groups to assign to this role.
- Multi-select combobox (type to search).
3. Click **Add Role**.
### Editing a Role
Navigate to Express Role Administration.
1. Find the role in the list.
2. Select  (**ellipsis**) for the role and select **Edit**.
3. Update the editable fields:
**Editable**:
**Read-Only**:
- Role Description.
- Select Parent (unless the role is a default role).
- Select Default Permission (unless the role is a default role).
- Full Submission Access (unless the role is a default role).
- Designer Access (Super-user) (deprecated; shown on every role while the environment still offers the option; see [Environment Administration](/unqorkai/docs/environment-administration#designer-access-deprecated). Locked on the NoAccess and Anonymous roles, which never carry it).
- Group assignments.
- Role Name (cannot be changed after creation).
4. Click **Save Changes**.
> Default roles (Administrator, Authenticated, NoAccess, Anonymous) have their parent, default permission, and super-user flags locked.
### Deleting a Role
Navigate to Express Role Administration.
1. Find the role in the list.
2. Select  (**ellipsis**) for the role and select **Delete**.
3. Confirm deletion in the dialog that displays.
**Restrictions**:
- Cannot delete default roles (Administrator, Authenticated, NoAccess, Anonymous).
- Cannot delete roles currently assigned to end-users (backend validation prevents this).
- Deletion is permanent: the role must be recreated from scratch if needed.
### Promoting Roles
**Promotion** copies roles from the current environment to a target environment (for example, Dev → QA → Production).
Navigate to Express Role Administration.
1. Select the **More actions** button in the top toolbar and select **Promote Roles**.
2. The Promote Roles dialog opens:
- All roles are selected by default.
- Use **Select All** / **Deselect All** buttons to manage selection.
- Check/uncheck individual roles to include or exclude them.
3. Select the **target environment** from the drop-down.
- Shows client name and level (for example, "Acme Corp - Production").
4. Click **Promote**.
**Result**: Selected roles are copied to the target environment with all properties preserved.
### Viewing Role Hierarchy
Navigate to Express Role Administration.
1. Select **View Role Hierarchy** in the top toolbar.
2. The **Role Hierarchy** dialog opens:
- Parent roles in bold.
- Child roles indented beneath their parent, joined to it by a guide line.
- Default permission badge for each role.
- Every role is listed, including roles with no parent and no children.
- Select a parent role to collapse or expand its children.
**Use Case**: Understand permission inheritance and visualize role relationships before making changes.
## Express Groups
Express Groups define **data access rules** between end-users based on role hierarchy. Groups control whether end-users can access each other's submissions and data.
### Group Properties
Each Express Group has the following properties:
| Property | Description | Example |
| --- | --- | --- |
| **Name** | Unique identifier for the group (alphanumeric + hyphens, cannot begin with hyphen) | `finance-team` |
| **Description** | Human-readable explanation of the group's purpose | "Finance department staff" |
| **Group Type** | Data access rule based on role hierarchy | `role_descendents`, `own_role_and_descendents`, or `ignore_role` |
### Group Types Explained
Group type determines whether end-users in the same group can access each other's data:
| Group Type | Access Rule | Example |
| --- | --- | --- |
| **Data access to role descendants** (`role_descendents`) | Alice can access Bob's submissions **only if** Alice's role is **higher** than Bob's in the hierarchy | Alice (Manager) can view Bob's (Staff) data, but Bob cannot view Alice's |
| **Data access to own role and role descendants** (`own_role_and_descendents`) | Alice can access Bob's submissions **if** Alice's role is **higher than or equal to** Bob's in the hierarchy | Alice (Manager) can view Bob's (Staff) data; Alice (Manager) can also view Carol's (Manager) data |
| **Data access to all roles in hierarchy** (`ignore_role`) | Alice can access Bob's submissions **regardless of role hierarchy** | All group members can view each other's data, no matter their role |
**Badge Colors**:
- Blue: `role_descendents`.
- Amber: `own_role_and_descendents`.
- Green: `ignore_role`.
## Managing Express Groups
### Viewing Existing Groups
Navigate to Express Group Administration in the UnqorkAI platform.
1. The group list displays:
- **Name**: The unique group identifier.
- **Description**: Purpose of the group.
- **Type**: Badge showing data access rule.
- **Actions**: Drop-down with Edit and Delete options.
2. Use the **search bar** to filter groups by name or description.
3. Pagination controls display at the bottom (default: 50 groups per page).
### Creating a Group
1. Navigate to Express Group Administration.
2. Click **Add Group**.
3. Fill in the form:
**Group Name** (required)
**Group Description** (optional)
**Group Type** (required)
- Alphanumeric characters and hyphens.
- Cannot begin with a hyphen.
- Maximum 255 characters.
- Must be unique.
- A warning displays below this field: "The group name is permanent and cannot be changed after creation."
- Explain the group's purpose and which end-users and roles should belong to it.
- Select of the following options:
- **Data access to role descendants**: Hierarchical access (higher roles can see lower roles' data).
- **Data access to own role and role descendants**: Hierarchical access including peers at the same role level.
- **Data access to all roles in hierarchy**: All members can see each other's data.
4. Click **Add Group**.
**Result**: The new group displays in the group list and can be assigned to roles.
### Editing a Group
Navigate to Express Group Administration.
1. Find the group in the list.
2. Select  (**ellipsis**) for the role and select **Edit**.
3. Update the editable fields:
**Editable**:
**Read-Only**:
- Group Description.
- Group Type.
- Group Name (cannot be changed after creation).
4. Click **Save Changes**.
**Note on Member Management**:
- Group membership (which end-users and roles belong to the group) is managed through:
- **Express Role Administration**: Assign roles to groups when creating or editing roles.
- **User Management**: Assign end-users to roles that belong to groups.
### Deleting a Group
Navigate to Express Group Administration.
1. Find the group in the list.
2. Select  (**ellipsis**) for the role and select **Delete**.
3. Confirm deletion in the dialog:
- "Remember, deleting a group is permanent. To make a group available again, you must re-add it from scratch and reassign all members."
**Restrictions**:
- No default groups exist (unlike roles).
- Deletion is immediate if the group is not in use.
- All role assignments to this group will be removed.
### Promoting Groups
**Promotion** copies groups from the current environment to a target environment (for example, Dev → QA → Production).
Navigate to Express Group Administration.
1. Click **Promote Groups** in the top action bar.
2. The Promote Groups dialog opens:
- All groups are selected by default.
- Use **Select All** / **Deselect All** buttons to manage selection.
- Check/uncheck individual groups to include or exclude them.
3. Select the **target environment** from the drop-down.
- Shows client name and level (for example, "Acme Corp - Production").
4. Click **Promote**.
**Result**: Selected groups are copied to the target environment with all properties preserved.
## Application Entry-Point RBAC
Application Entry-Point RBAC lets Administrators assign a specific Express Role to an individual end-user for a specific application. The assigned role overrides the end-user's default Express Role, but for that application's entry-point module.
Configure Application Entry-Point roles in the **Application Roles** section when editing an individual end-user in Express User Administration.
### Settings
Each application in the environment has a row in the table. The table includes the following columns:
| Column | Description |
| --- | --- |
| **Title** | The application name. |
| **Type** | The application type: Module or Workflow. |
| **Role** | The Express Role assigned to this end-user for this application. Select **Inherit** to apply the end-user's default Express Role. |
| **Effective Role** | The role that resolves for this application: the assigned role, or the default Express Role when **Inherit** is selected. |
| **Inherited From** | Displays **Default Role** when the end-user's environment-level Express Role applies. |
### Security Limitation
> [!WARNING]
> Application Entry-Point RBAC gates access to the application's **entry-point module**. End-users can navigate directly to a sub-module URL and bypass this restriction.
>
>
> To restrict access to sub-modules in an application, 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.
## How Roles and Groups Work Together
### Relationship Overview
1. **Roles are assigned to Groups**.
- Roles are assigned to or more groups when creating or editing the role.
- Roles have a `groups: string[]` property listing all group memberships.
2. **End-users inherit Group memberships through Roles**.
- An end-user assigned to a role automatically belongs to all groups assigned to that role.
- End-users can belong to multiple groups if they have multiple roles.
3. **Groups control data access**.
- Group type determines how end-users with different roles can access each other's data.
- Role hierarchy (parent-child relationships) is independent of group membership.
- Groups layer additional data-access control over the role hierarchy.
### Example Scenario
**Setup**:
- **Role:** `claims-reviewer` (parent: `standard-user`, default permission: `read`).
- **Role:** `claims-adjuster` (parent: `claims-reviewer`, default permission: `write`).
- **Group:** `claims-team` (type: `role_descendents`).
- Both roles are assigned to the `claims-team` group.
**End-users**:
- Alice has the `claims-reviewer` role (higher in hierarchy).
- Bob has the `claims-adjuster` role (child of claims-reviewer, lower in the hierarchy).
**Result**:
- Alice can view Bob's submissions (she's higher in the hierarchy).
- Bob **cannot** view Alice's submissions (he's lower in the hierarchy).
- Both end-users can create and edit their own submissions.
- If the group type were `ignore_role`, both could view each other's submissions regardless of hierarchy.
## Best Practices
### Role Management
1. **Define a clear role hierarchy**.
- Begin with broad roles (for example, "Standard User") and create specialized child roles.
- Document role relationships and inheritance chains.
2. **Use descriptive role names**.
- Use hyphens instead of spaces (for example, `claims-adjuster`).
- Keep names short but meaningful.
3. **Limit super user flags**.
- Grant Designer Access and Full Submission Access to trusted administrators.
- Regularly audit who has these elevated permissions.
4. **Test before promoting**.
- Create roles in a Dev or Test environment first.
- Validate permissions work as expected before promoting to Production.
5. **Assign groups during role creation**.
- Think about data access rules when creating roles.
- Assign roles to groups that match their data access needs.
### Group Management
1. **Choose the right group type**.
- Use `role_descendents` for hierarchical teams (managers see staff data).
- Use `own_role_and_descendents` for peer collaboration (team members at same level share data).
- Use `ignore_role` sparingly: when all members truly need equal data access.
2. **Keep group membership organized**.
- Assign roles to groups, not individual end-users.
- Update group type if data access rules change.
3. **Document group purposes**.
- Use clear descriptions explaining who should belong to the group.
- Note any special data access considerations.
4. **Review group assignments regularly**.
- Audit which roles belong to which groups.
- Remove inactive or obsolete groups.
**Changelog**
| Date | Change |
| --- | --- |
| 2026-09-04 | Corrected when Designer Access (Super-user) appears - every role while the environment still offers it, locked on NoAccess and Anonymous. |
| 2026-08-27 | Corrected View Role Hierarchy access - inline toolbar button, not More actions button (EN-8047). |
| 2026-08-20 | Noted that Designer Access (Super-user) is deprecated and can be retired environment-wide. |
| 2026-07-29 | Added Application Entry-Point RBAC section including settings table and 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.
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.
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.
In Unqork an application is a program used to perform specific tasks. An application can be one of two types: workflow or module.
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.
Use your QA (quality assurance) environment to test applications to ensure reliability, security, and functionality before releasing them to the end-user.
The Production environment is the final stage of the development process. Use this environment to promote tested and functioning application so your end-user can interact with it.
A URL (uniform resource locator) is a unique identifier used to locate a resource on the internet. Also known as a web address.
A JavaScript property is a member of an object that associates a key with a value. A JavaScript object is a data structure that stores a collection of properties.