Process engine variable scope

A workflow process often needs information about its environment when executing service tasks. For instance, the ServiceTask that invokes a web service may need host, port, and username/passwords details to invoke an external service successfully. Configuring these values inside the workflow definition is problematic when promoting a definition change between dev/test/prod environments. Having a client supply these values as a process variable improves things in many respects, but it still requires the variables to be updated in every instance that references them when the environment changes.

In the Version 6 launch in Paris in 2015 referenced in this bog post, on slide 56 there is a references to “System variables”. I believe that was explained as providing a process engine variable scope for system environment variables.

Has there been any more thought or work done on this topic?

Hi David,

We have been thinking about putting variables into a VariableService that would allow you to not only create variables for a process instance or task, but also system wide environment variables or process definition specific variables. This is something we would like to work on after the 6.0 is released. Let us know if you have specific ideas about this as well, it’s still something that needs quite a bit of thinking.

Best regards,



Hi, my 2 cents on this:
system-wide variables or process-definition variables are definitely something very useful.
The question could be even made more generic into “how could I create some custom ‘getter’ methods that can be used in JUEL expressions; where these ‘getter’ methods return data from a datasource which is not the flowable process variables?”

So for example, applied to system global variables, that would mean

  • You have to create your own datasource to store the system settings (use file, any relational DB, or Mongo, whatever)

  • You have to create a library with static getter functions . Under the hood, the getter functions do the calls to the datasource. For example, create a method that retrieves a String Value given a Key as string .

  • Then, one would create a JUEL expression, for example setting the property with value ${MyOwnSystemsettingsLibrary.getStringValue(“funkyWebserviceURL”)}

Though not being a developer myself, my little toe feels that addressing other datasources could be quite tricky. Limiting the scope to getters would definitely reduce headaches of multi-datasource transactions. The user guide talks about using Beans in chapter 4.6 (${myBean.doSomething(myVar, execution)}) ; but I guess it wouldn’t be that simple ?

My preference would be that Flowable’s default variable resolution would work with variables scoped at the engine level. For instance, if the variable was not found at the process instance execution scope, Flowable would then attempt to resolve the variable at the engine level scope (if engine level variable support was enabled). Support for engine level variables also needs to take into account multi-tenancy as one tenant may have a need to define different environment variables than another tenant.


@pieterclaeys You can already use Spring beans or standard Java beans in JUEL expressions in Flowable. So it’s easy to expose a bean that retrieves values from a database or another resource in that way. We could expose an engine variable bean that allows you to directly get a variable value. That would improve the performance because you don’t have to look first on the execution scope level etc.

@robert.hafner Yes, I agree as well. And yes, this needs multi-tenancy support built-in.

Best regards,


What about interfacing associations (rules starting with =) of variables from different scopes (including engine, environment, execution or more importantly to me, previous tasks). Or is the task variable association already available there at the definition or the process instance level.

since it “needs quite a bit of thinking”, I am stretching thin with my limited understanding here for you:-), my 2 cents -since Flowable next is to allow change state of a running process instance to a previous activity (is it allow looping?) or future activity or concurrency if applied to variables next. Perhaps a guard for variables or limiting such support to only transient variables may help?

+1 for setting up a way to do this without java coding.

Regarding java, would anyone mind sharing an example of how I could get an instance’s executionid value inside a variable? I’d like to use it inside an http task inside a process. I’m not a java coder.


Was there a follow up of this subject? Is it possible to manipulate variables related to a process Definition? In my use case I want to manipulate variables, before the process is activated and a new instance generated…

No, variables on definitions are not supported.

Can’t you do that programmatically? Or do you mean you want to base yourself on the definition, show them to the user and let them manipulate them?

Thanks for your reply Joram.

I considered 2 options:

  1. Create a custom table (similar to act_ru_variable) and store there custom data for process definition;
  2. Read the bpmn of the xml with getRepositoryService().getBpmnModel and extract the values that I want from the extensionsElements.

I decided to use 2). I know it is not the best solution (for CRUD operations the 1) will be better)…

Thanks for your attention.