--- title: "Designer Role-Based Access Control (RBAC) Overview" slug: "designer-role-based-access-control-rbac-overview" tags: ["rbac", "security"] updated: 2026-09-15T15:44:04Z published: 2026-09-15T15:44:04Z canonical: "docs.unqork.io/designer-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. # Understanding Designer Role-Based Access Control (RBAC) Designer Role-Based Access Control (RBAC) controls who can build applications in Unqork and what they can do in Module Builder. This is separate from Express RBAC, which controls end-user access to applications. ## What Is Designer RBAC? Designer RBAC controls access to the Module Builder and determines what Creators can build, view, edit, or delete. ### What Designer RBAC Controls **Protected resources include the following:** - Applications and modules. - Data models and schemas. - Services and integrations. - Styles and themes. - PDF templates. - Managed assets. - Reference data collections. - Record queries. - Creator user management. **Actions controlled include the following:** - **View**: Can see and open resources. - **Create**: Can create new resources. - **Update**: Can edit existing resources. - **Delete**: Can remove resources. - **Promote**: Can promote resources between environments. ### Who Uses Designer RBAC **Configured by**: Environment Administrators. **Applied to**: Creators (developers, solution architects, and system administrators). **Purpose**: Control who can build applications and what resources they can access in the UnqorkAI platform. ## Designer RBAC vs. Express RBAC ### Key Differences **Designer RBAC**: - Controls **UnqorkAI Platform access** for Creators. - Two levels: **Environment-level** (Creator Roles) and **Workspace-level** (Workspace permissions). - Determines who can build or edit modules. - Examples: "Can Alice create applications?", "Can Bob edit data models in Workspace A?". **Express RBAC**: - Controls **application access** for end-users. - Three levels: **Environment-level** (Express Roles), **Module-level**, and **Component-level**. - Determines who can use modules and view or edit data. - Examples: "Can end-users see this module?", "Can managers edit this field?". ### Same Person Can Have Both Roles A Creator can have: - **Creator Role**: The Designer RBAC role that determines what they can build. - **Express Role**: The Express RBAC role that determines what they can test or view in applications. **Example**: - **Alice** is a (Creator Role) who can build applications in Workspace Finance. - **Alice** also has the Standard User role (Express Role) to test applications. - These are independent; Alice's Designer RBAC doesn't affect her Express permissions. ## Two Levels of Designer RBAC Designer RBAC operates at two levels: ### 1. Environment-Level (Creator Roles) **What it controls**: Baseline permissions across all workspaces in the environment. **Assigned by**: Creator Roles (Administrator, Contributor, Viewer, and so on). **Determines the following:** - Which resource types a Creator can access. - What actions they can perform on resources (view, create, update, delete, and promote). - Whether they can access Administration pages. ### 2. Workspace-Level (Workspace Permissions) **What it controls**: Access to specific workspaces. **Assigned by**: Workspace roles (CAN_MANAGE, CAN_EDIT, CAN_VIEW, or NO_ACCESS). **Determines the following:** - Which workspaces a Creator can access. - What they can do in those workspaces. - Whether they can promote workspace content. ### How They Work Together Creators must satisfy both of the following requirements: 1. Creator must have permission in their **Creator Role** (for the resource type). 2. Creator must have permission in their **Workspace role** (for that specific workspace). **Example**: - **Creator Role**: Contributor (can create, edit, and delete applications). - **Workspace Role**: CAN_VIEW in Workspace A. - **Result**: The workspace role restricts access to view only; the Creator cannot create or edit. **Rule**: The most restrictive permission between Creator Role and Workspace role applies for that workspace. ## Environment-Level Designer RBAC (Creator Roles) Creator Roles are **named permission sets** that define what resource types a Creator can access across the environment. ### Default Creator Roles Unqork provides four default Creator Roles: | Role | Can Edit? | Admin Access? | Description | | --- | --- | --- | --- | | **Administrator** | No (immutable) | Yes | Full access to all resources and Administration pages. | | **Contributor** | Yes | No | Create, edit, and delete in assigned workspaces; standard role for Creators. | | **Viewer** | Yes | No | Read-only access to workspace resources. | | **Environment:BASIC** | No (immutable) | No | Login access only; no UnqorkAI platform access. | ### Permission Structure Creator Roles grant permissions for **resource types** and **actions**: **Actions (Hierarchical) include the following:** - **View (v)**: Read-only access. - **Update (u)**: Edit existing resources (requires View). - **Create (c)**: Create new resources (requires View and Update). - **Delete (d)**: Delete resources (requires View, Update, and Create). - **Promote (p)**: Promote between environments (requires View). **Example Permission Matrix**: | Resource Type | Administrator | Contributor | Viewer | | --- | --- | --- | --- | | Application | v, c, u, d, p | v, c, u, d, p | v | | Data Model | v, c, u, d, p | v, c, u, d, p | v | | Services | v, c, u, d, p | v | v | | Creator User Management | v, c, u, d | — | — | ## Workspace-Level Designer RBAC Workspaces are **containers for related resources** (applications, modules, and data models) that provide a second level of access control. ### Workspace Permission Levels There are **four workspace permission levels** (in order of privilege): #### 1. CAN_MANAGE (Highest Privilege) **What it grants**: - View, create, edit, delete, and promote all workspace content. - Update workspace settings. - Manage services and data models. - Full control over workspace. **When to use**: Workspace owners and team leads. #### 2. CAN_EDIT **What it grants**: - View, create, edit, and delete workspace content. - Manage data models. - View shared library elements. - **Cannot** promote workspace content. **When to use**: Active developers on the team. #### 3. CAN_VIEW (Read-Only Access) **What it grants**: - Read-only access to workspace content. - View library elements and data models. - **Cannot** modify, promote, or delete. **When to use**: Auditors, stakeholders, and reviewers. #### 4. NO_ACCESS (Explicit Restriction) **What it grants**: - No access to workspace content. - Used to restrict a Creator whose Creator Role otherwise grants access. **When to use**: Explicitly block access to sensitive workspaces. ### Workspace Role Assignment Creators are assigned workspace roles in one of the following two ways: **1. Workspace-Specific Permissions** - Creators added to individual workspaces. - No automatic access to other workspaces. - No access to Administration pages. - **Use for**: Developers and solution architects. **2. Environment-Wide Permissions** - Automatic CAN_MANAGE access to **all workspaces**. - Access to Administration pages. - Cannot be removed from individual workspaces. - **Set using**: Administrator Creator Role. - **Use for**: System administrators. ## Where to Configure Designer RBAC ### Environment-Level (Creator Roles) **Navigation**: Creator Role Administration. This page lets Creators: - View all Creator Roles. - Create new Creator Roles. - Edit existing Creator Roles (if editable). - Delete Creator Roles (if not default or in use). - Configure resource-level permissions for each role. **Configuration options include the following:** - Role name and description. - Permissions for each resource type (application, data model, services, and so on). - Actions allowed (view, create, update, delete, and promote). **Who can access**: Creators with Administrator role or permissions to access the Creator Role administration page. > [!NOTE] > To assign a Creator's environment-level role (Administrator, Contributor, and so on), navigate to Creator (User) Administration. ### Workspace-Level (Workspace Permissions) **Navigation**: Open the workspace, then from the **Definition** drop-down, select **Permissions**. This page lets Creators: - View all Creators currently assigned to this workspace. - Add new Creators to the workspace. - Set permission level for each Creator (CAN_MANAGE, CAN_EDIT, CAN_VIEW, or NO_ACCESS). - Remove Creators from the workspace. **Configuration options include the following:** - Which Creators have access to this specific workspace. - Permission level per Creator (CAN_MANAGE, CAN_EDIT, CAN_VIEW, or NO_ACCESS). - Individual workspace assignments (repeat for each workspace). **Who can access**: Creators with CAN_MANAGE permission for that workspace or Administrator role. ## Permission Resolution ### How Designer Permissions Are Evaluated When a Creator tries to access a resource: 1. **Check Creator Role**: Does the Creator Role grant permission for this resource type and action? 2. **Check Workspace Role**: Does the Workspace role grant permission for this workspace? 3. **Apply Restrictions**: Use the **most restrictive** of the two. ### Examples **Example 1: Creator Role Allows, Workspace Restricts** - **Creator Role**: Contributor (can create, edit, and delete applications). - **Workspace Role**: CAN_VIEW. - **Result**: The workspace role restricts access to view only. **Example 2: Workspace Allows, Creator Role Restricts** - **Creator Role**: Viewer (can view applications). - **Workspace Role**: CAN_MANAGE. - **Result**: The Creator Role restricts access to view only. **Example 3: Both Grant Access** - **Creator Role**: Contributor (can create, edit, and delete applications). - **Workspace Role**: CAN_EDIT. - **Result**: Can create, edit, and delete. Both the Creator Role and Workspace role grant access. **Example 4: Explicit NO_ACCESS** - **Creator Role**: Administrator (full access). - **Workspace Role**: NO_ACCESS. - **Result**: No access—the explicit NO_ACCESS restriction applies regardless of Creator Role. ## When to Use Designer RBAC ### Defining Baseline Permissions - Set organization-wide policies for what Creators can do. - Create standard roles for different team levels. - Grant environment-wide access to administrators. > [!TIP] > For example, all developers get the Contributor role and auditors get the Viewer role. ### Controlling Project Access - Restrict Creators to specific projects or teams. - Provide temporary access to external contractors. - Isolate sensitive or confidential projects. > [!TIP] > For example, the Finance team gets **CAN_MANAGE** in the Finance workspace and **CAN_VIEW** in the Audit workspace. ### Managing Complex Organizations - Different teams working on different projects. - External contractors needing limited access. - Compliance requirements for data segregation. > [!TIP] > For example, Developer A has the Contributor role with **CAN_EDIT** in Project X, and Developer B has the Contributor role with **CAN_MANAGE** in Project Y. ## Best Practices ### 1. Use the Principle of Least Privilege - Grant only the permissions necessary for the Creator's role. - Begin with Viewer or CAN_VIEW and increase as needed. - Regularly review and revoke unnecessary permissions. ### 2. Separate Concerns with Workspaces - Organize resources by project, team, or application. - Use workspace permissions to isolate sensitive projects. - Restrict cross-workspace access unless necessary. ### 3. Document Permission Decisions - Maintain a matrix of who has access to what. - Document why specific Creators have elevated permissions. - Review permissions during onboarding/offboarding. ### 4. Limit Administrator Roles - Only assign Administrator to system admins. - Use Contributor + CAN_MANAGE for project-level admins. - Regularly audit who has Administrator access. ### 5. Use Environment:BASIC for Special Cases - External contractors with limited workspace access. - Service accounts that need login but not UnqorkAI platform access. - Temporary accounts for audits or reviews. ### 6. Test with Real Accounts - Verify permissions work as expected before granting access. - Test edge cases like multi-workspace access. - Use test Creator accounts with different role assignments to verify behavior. 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. PDF (Portable Document Format) is a file format that allows users to share and print documents without modifying them. A query lets you retrieve, access, manipulate, and delete data in a database. 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. Elements are are what you use to build Unqork applications. Elements include modules, workflows, Data Collections, Data Schema, and Record Collections.