Camunda Unified API V2 Tasklist Variables

Camunda 8 Topics
1

Hello guys, i have a question about 8.8.
The unified tasklist api (/v2/user-tasks/:userTaskKey/variables/search) now returns all available process variables and the scope even when input variables are set.
Is this wanted behavior?
This makes input mapping obsolete and could result into picking a wrong variable when variables have the same key in different scopes.Currently its not possible to toggle between getting all variables or just the scope
Currently its not possible to set a scope filter in the request.The only way to handle this correctly seems to
call /v2/user-tasks/:userTaskKey to get the elementId and then use it as a filter on the response from the search endpoint or
use unique variable naming in the input mapping and use the name filter in the requestSo basically we need to alway make min. 2 api calls to get the elementId + all pages from the variables/search to make sure we get all variables?

2

Hi @OwndbyFab,

Thank you for bringing up this important question about the Camunda 8.8 unified API v2 behavior!

Classification: Problem - You’re experiencing unexpected behavior with variable scoping in the unified API.

Based on the current documentation and known limitations, what you’re experiencing appears to be related to known gaps in the unified REST API v2. Here’s what we know:

Current State of API v2 Variable Handling

The unified Camunda 8 REST API (v2) in version 8.8 has limited variable querying capabilities compared to Tasklist API v1. Specifically:

  • No scope filtering: The v2 API doesn’t provide mechanisms to filter variables by scope (local vs process instance)
  • No input mapping awareness: The API doesn’t distinguish between variables that should be scoped due to input mapping vs all available variables
  • Limited variable controls: Features like includeVariables parameter available in v1 are not yet implemented in v2

Your Observations Are Valid Concerns

Your points about this behavior are absolutely correct:

  1. Input mapping becomes ineffective if all variables are returned regardless of scope
  2. Variable name conflicts can occur when the same key exists in different scopes
  3. Multiple API calls required to properly filter results client-side

Recommended Actions

Since this behavior seems unintended and problematic for proper variable scoping:

  1. File a GitHub issue at GitHub · Where software is built with:

    • Your Camunda version (8.8)
    • Environment (SaaS/Self-Managed)
    • Expected behavior: Only scoped variables should be returned when input mapping is configured
    • Actual behavior: All process variables are returned regardless of input mapping
    • Your use case and why this is problematic

  2. Consider using Tasklist API v1 temporarily if you need more precise variable control, though even v1 doesn’t have explicit scope filtering

  3. Monitor the roadmap at https://roadmap.camunda.com/ for API v2 enhancements

Workaround

Your suggested approaches are currently the best available:

  • Use /v2/user-tasks/:userTaskKey to get elementId, then filter client-side
  • Use unique variable naming in input mapping with name filters

Would you be able to file this as a GitHub issue? This seems like important feedback for the API v2 development team.

References:

3

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