Accessing variables

Hi - is there any way in a task to access variables such as:

  • the workflow instance number as displayed by operate
  • the process id defined in the bpmn:process tag

e.g. <bpmn:process id=“process_close_customer_accounts_V2” name=“Close Customer accounts” isExecutable=“true”>

Any help much appreciated!

Regards - Stephen H in sunny OZ (although winter is coming…)


a job worker can access some context information of the job. For example, the workflow instance key and the BPMN process id. See also:

How to access these properties depends on the client that you’re using.

Does this help you?

Best regards,

1 Like

Thanks Philipp - that’ll do.

Hi Philipp - follow up question. I have a sub-process being called. When I am in the sub-process is there any way of identifying what has invoked it?

I need more context information to answer this question. In general, the job contains only the information of the current element that is executed. Workflow instance variables are a way to provide or pass additional informations.

Hi Philipp - Thanks for the response. We’re a large organisation and looking at federating out building of processes and enabling reuse. With our APIs each consumer of an API is authorised. We need a similiar level of control over sub-processes so that we can enable reuse across the organisation. What we would like to be able to do is have a way to authorise what has called the sub process. To do this we need a tamper proof way of getting the identity of what has called it. Unfortunately passing in a variable would be subject to tampering…

Just to add - this won’t be a problem for the initial invocation as we’ll use TLS-MA. It becomes a problem when we start calling sub-processes.

What exactly do you mean with


I understand that

  • you have common business logic that is part of multiple workflows
  • you extracted the common logic into workflows that are called via call activity
  • you want to restrict the usage of the workflows based on some sort of authorization

Is this correct? Any other requirements? More context? Any workflow example?

Hi Phillipp - thats correct.

An example would be:

  • A sub process is defined to do an automated credit check on a customer.
  • This sub process is called via an activity by other processes such as credit card origination, personal loan origination etc

The requirement is to be able to authorise the caller of a sub-process.

Thank you for the example :slight_smile:

There is no authorization within Zeebe to prevent that a sub-process is called from another workflow.

One way is to use workflow instance variables. When the sub-process is created then it checks if the variable has a specific value (e.g. a tenant-id or organization name). If the value doesn’t match then it ends the sub-process without performing the checks.

This check could be also done within the workers of the sub-process or using data of the application context.

Does this help you?

Hi Philipp - unfortunately it wouldn’t be secure enough. Is there a possibility of me raising a feature to get this included? The ask would be to include the id and name of the calling process in the sub-process…

Of course! You can create an issue here: Sign in to GitHub · GitHub

So, you propose to add information about the calling workflow instance to the activated job properties?

This may be also a bit limiting, for example, if multiple sub-process are involved.


For us this would be ok. For example it you have the situation:

Process A calls Process B calls Process C

We would authorise Process B to call Process C and
Process A to call Process B.
Process C doesn’t need to know that Process A is at the top of the chain as by inference it has the right to call process C having been given the rights to call Process B.