Camunda version: 8.8
We are using the OIDC authentication method, meaning user authentication is handled by Keycloak, while group and role management is handled by Camunda Identity.
My understanding is that the Assignment feature should allow restricting operations on a USER TASK by user or group.
Here is my question:
I want a USER TASK created in Camunda Modeler to be visible only to users belonging to “Group A” defined in Identity UI.(Display in Tasklist UI)
According to this documentation, user task access restrictions are only supported in Tasklist v1.
This means that in our current orchestration cluster setup, features like candidate users or candidate groups for restricting user access cannot be used.
My question is:
If we want to achieve similar behavior—restricting access to user tasks based on users or groups—in an orchestration cluster, what is the recommended approach?
Great question! You’re on the right track with using candidate groups to restrict user task visibility. Let me walk you through the complete configuration for your Camunda 8.8 setup with OIDC and Keycloak.
How Candidate Groups Work
In BPMN user tasks, candidateGroups is a list of strings that must match the group names that Camunda knows about via Identity/OIDC claims. When user task access restrictions are enabled, a user sees a task in Tasklist only if they are:
The assignee, or
Listed in candidateUsers, or
A member of one of the candidateGroups
Required Configuration
1. Keycloak Configuration
Ensure your Keycloak users have group information in their tokens. Typically this comes through a groups claim in the OIDC token.
2. Identity UI Configuration
You need to configure Orchestration Identity (not Management Identity):
Important: Make sure you’re accessing the Orchestration Identity UI and that you have RESOURCE_PERMISSIONS_ENABLED=true to see Groups and Authorizations tabs.
Groups: Create or map your groups (e.g., “Group A”)
Mapping Rules: Map Keycloak claims to Identity groups
Map the groups claim containing GroupA from Keycloak to an Identity group named GroupA
Authorizations: Set up appropriate permissions for the group
3. Camunda Modeler Configuration
In your user task’s Assignments section:
Set Candidate groups to the exact group name: GroupA
This can be static text or an expression that evaluates to a list of strings
4. Tasklist Configuration
Critical: You must use Tasklist V1 mode with “Enforce user task restrictions” enabled in your Console/cluster settings.
Important Limitation: If you’re using Tasklist V2 API or custom frontends, candidate groups are not enforced by Camunda. You’d need to implement custom authorization logic in your backend.
Step-by-Step Setup
Verify Orchestration Identity access: Ensure you can see Groups and Authorizations tabs
Create mapping rules: Map Keycloak groups to Identity groups with exact names
Set candidate groups in Modeler: Use the exact group name (e.g., GroupA)
Enable user task restrictions: Keep this enabled in Tasklist V1 mode
Test: Users in “Group A” should only see tasks with candidateGroups containing GroupA
Troubleshooting
If candidate groups aren’t working as expected:
Verify you’re using Tasklist V1 (not V2)
Check that user task access restrictions are enabled
Ensure group names match exactly between Identity and BPMN
Confirm users are properly mapped to groups via mapping rules
In our environment, the Camunda version is 8.8, which means we are using the Orchestration Cluster API.
In this case, the Tasklist version should be V2. Indeed, it seems that the Candidate Groups feature in Camunda Modeler is not working as expected.
I would like to ask about the following two points:
How can I check which Tasklist version is currently active?
Perfect! You’ve identified the exact issue. Since you’re using Camunda 8.8, Tasklist V2 is indeed the default, and that’s why your candidate groups aren’t working as expected.
1. How to Check Current Tasklist Version
In Camunda 8.8+, V2 is the default. There’s no explicit version label in the UI, but you can determine this by:
If you haven’t changed any Tasklist configuration: You’re on V2
Check your configuration: Look for the V2ModeEnabled setting (see below)
2. How to Switch to Tasklist V1
Since you’re using Docker containers (Self-Managed), you can switch to V1 using environment variables or YAML configuration:
Option A: Environment Variable
CAMUNDA_TASKLIST_V2_MODE_ENABLED=false # Use V1
Option B: YAML Configuration
camunda:
tasklist:
V2ModeEnabled: false # Use V1
Where:
false = Tasklist V1 (supports candidate groups)
true = Tasklist V2 (default in 8.8+, no candidate group support)
3. Complete Solution for Your Use Case
To get candidate groups working with “Group A” visibility:
Switch to Tasklist V1: Set CAMUNDA_TASKLIST_V2_MODE_ENABLED=false
Enable user task access restrictions: In Console → Clusters → Settings, ensure “Enforce user task restrictions” is enabled
Configure Identity mapping: Set up mapping rules from Keycloak groups to Identity groups
Set candidate groups in Modeler: Use the exact group name (e.g., GroupA)
Important Notes
User task access restrictions only work with Tasklist V1
In V2, candidate users/groups don’t affect task visibility - you’d need to implement custom authorization logic
The Console setting “Enforce user task restrictions” only has effect when using V1
After switching to V1 and restarting your containers, your candidate groups should work as expected, restricting task visibility to users in “Group A”.
Important Limitation: If you’re using Tasklist V2 API or custom frontends, candidate groups are not enforced by Camunda. You’d need to implement custom authorization logic in your backend.