Tasklist V2 in Camunda 8.8: candidateGroup no longer restricts task visibility – what is the recommended approach?

Hi Team,

We are currently migrating our workflow application to Camunda Platform 8.8 (Self-Managed) and discovered that Tasklist V2 is now the default.
During our testing, we found that BPMN candidateGroup no longer affects task visibility or assignment.

According to the official documentation:

This means that the task visibility control we relied on in previous versions (Tasklist V1 behavior) no longer works in Camunda 8.8+.


Our use case

We have a single BPMN workflow separated into two swimlanes:

  • Lane 1 → GroupA

  • Lane 2 → GroupB

Each lane corresponds to a different business team.

Example structure:

Start

[User Task X] ← Lane 1 (candidateGroup = “GroupA”)

[User Task Y] ← Lane 2 (candidateGroup = “GroupB”)

End

In Tasklist V1, we could:

  • Assign users to groups such as GroupA and GroupB

  • Set candidateGroup values in BPMN

  • And Tasklist would show each user only the tasks belonging to their group

This behavior is essential for our business requirements.


Problem with Camunda 8.8 (Tasklist V2)

Even though:

  • Identity Roles = GroupA and GroupB

  • Users receive these roles correctly through OIDC mapping

  • BPMN defines candidateGroup=“GroupA” / candidateGroup=“GroupB”

Tasklist V2 shows all user tasks to all authenticated users, completely ignoring the BPMN candidate groups.

As a result, we can no longer separate visibility of tasks within the same workflow.


Question

What is the official recommended approach to replace candidateGroup-based task visibility in Tasklist V2?

Should we consider:

  • Authorization-based task visibility?

  • Custom front-end + Orchestration API filtering?

  • Separating workflows per team (e.g., one process for GroupA and another for GroupB)?

  • Or is candidateGroup functionality planned to return in future V2 releases?


Environment

  • Camunda Platform 8.8 (Self-Managed)

  • Tasklist V2 (default)

  • Keycloak + OIDC authentication

  • Identity role mapping used for group assignment

Any guidance on best practices for task visibility control under Tasklist V2 would be greatly appreciated.

Thank you!

Hi @camundaman12345 - yes, this is a bit annoying on 8.8. The good news is that filtering like you expect with the V2 API will be available in 8.9. So it becomes a question of what do you want to do between now and then?

Authorization-based access controls only work at a process definition level, not individual user tasks. So you can limit visibility within Tasklist to a group for a specific process definition with this, but that’s not how your process is currently designed. I think a custom front end is probably too much, knowing this is coming in 8.9, unless there are other features you want to enable with a custom task application.

Could you use the V1 API until the functionality is available in 8.9?

2 Likes

I’m planning to try Tasklist v1.
I have two new questions:

Is there a way to check which Tasklist API version is currently active?
→ After switching to v1, I want to confirm that it’s actually enabled.

When is the scheduled release date for Camunda 8.9?

Thank you in advance.

Hi @camundaman12345

Open your browser’s developer tools. In the Sources tab, check the value of clientMode in the client-config.js file (as shown in the screenshot)

Alternatively, you can go to the Network tab and inspect the request URL of any API call (as shown in the screenshot)

2 Likes

@nathan.loding

Do you mean authorization-based permissions at user task level?

@hassang - yes, but I don’t think it’s quite the authorization you are wanting, it is still different than the C7 model. You can follow the epic here: Task permission management · Issue #39992 · camunda/camunda · GitHub

@camundaman12345 - 8.9 is currently scheduled for April.

1 Like

It serves the need and if I understand correctly this solution is supposed to be more efficient.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.