Designer Role-Based Access Control (RBAC) Overview

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

Designer RBAC vs. Express RBAC

Key Differences

Designer RBAC:

• Controls Unqork 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 contributor (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:

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:

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: Administration > Creator Permissions > 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 Administration > Creator Permissions > 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 IDE 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.