Skip to main content
Control what users see and edit within the same process instance based on their roles, usernames, or process data. One process adapts to different users automatically.

​
How it works

Permission-based expressions control UI element visibility and interaction. Configure different views for different user types in a single process definition.

Partial Editing

Specific users, roles, or usernames have tailored access to different UI elements within the same process

Read-Only Capabilities

Users can view process instances and navigate through user tasks without making changes

Multiple Executors

Multiple users with different roles can work concurrently on the same process instance within the same swimlane

Dynamic Adaptation

The same process interface adapts in real-time based on user permissions and process context

​
Permission types

​
Partial editing

Set different hide or disable permissions for specific users, roles, or usernames within the same swimlane.
  • Role-based: Different roles see different UI elements
  • Username-specific: Individual users have customized access
  • Process data driven: Use process data to determine permissions

​
Read-only access

Users view process instances without making changes. Requirements:
  • Users navigate user tasks but cannot modify data
  • Hide and disable conditions still apply
  • Must be configured at the process level
Execute or view permissions don’t automatically enable read-only mode. Configure read-only access explicitly in process settings.

​
How permissions work

Permissions combine three elements:

​
Swimlane roles

  • Configure roles at the swimlane level
  • Enable multiple executors to use permission-based expressions

​
UI element conditions

Hide condition
  • Removes UI element from interface
  • Available for all components
Disable condition
  • Shows element but prevents interaction
  • Available for forms, form elements, and buttons
  • Element appears grayed out

​
Precedence rule

When both hide and disable conditions exist on the same element, disable takes precedence.

​
Configure permissions

Permission Configuration Interface
1

Enable multiple executors

In process settings, enable Allow multiple executors for your swimlane.
Allow Multiple Executors Configuration
2

Select component

In UI Designer, select the component to configure.
3

Open permissions

Expand the Permissions section.
4

Add condition

Click + next to the condition type:
  • Hide Condition: All components
  • Disable Condition: Forms, form elements, buttons
5

Set parameters

Configure the condition:Type
  • USERNAME: Control by username
  • ROLE: Control by user role
Operator
  • IN: User must have role/username
  • NOT_IN: User must not have role/username
Value Type
  • SWIMLANE_OWNER: Current swimlane owner (no value needed)
  • PROCESS_DATA: Reference data from process instance
  • CONFIGURATION_SWIMLANE_ROLE: Use roles configured on swimlane
Value
  • PROCESS_DATA: Keypath to data (e.g., ${app.client.userList})
  • CONFIGURATION_SWIMLANE_ROLE: Array of role names (e.g., ["ROLE_1", "ROLE_2"])
  • SWIMLANE_OWNER: Not applicable (automatic)
Use CONFIGURATION_SWIMLANE_ROLE for roles configured as swimlane permissions. Use PROCESS_DATA for dynamic values from the process instance.
6

Save

Click Save.

​
Multiple executors

Enable Allow multiple executors to let multiple users work on the same process instance with different permissions. Requirements:
  • Enable at swimlane level in process settings
  • Set minimum role permissions:
    • Execute and Self-assign: For action users
    • View: For read-only users

​
Expression examples

{
  "type": "ROLE",
  "operator": "IN",
  "valueType": "CONFIGURATION_SWIMLANE_ROLE",
  "value": ["ROLE_1", "ROLE_2"]
}
When using PROCESS_DATA, map data to the keypath before users reach the user task. Arrays in process data should contain username or role strings.

​
Cross-swimlane references

SWIMLANE_OWNER is always scoped to the current swimlane. You cannot directly reference owners from other swimlanes.

​
Alternative: Use process data

To reference users from other swimlanes, store their information in process data: 
// Store when process starts or during transitions
{
  "swimlaneOwners": {
    "frontOffice": "user123",
    "backOffice": "user456", 
    "supervisor": "user789"
  }
}
Cross-swimlane owner references require explicit data mapping. Design your process to capture necessary user information during swimlane transitions.

​
Benefits

  • Users see only relevant information for their role
  • Hide sensitive data from unauthorized users
  • Single process definition for multiple user types
  • Multiple teams collaborate on the same process instance
⌘I