Tenant Variables (Local Settings)

Required Access Level

Admin or Super Admin

Tenant Variables hold static keys and values that the platform injects as process variables every time an instance starts. They belong to one process at a time: each variable is stored together with the key of the process it belongs to, and the same name — exchange_rate, say — can exist with different values in different processes.

A variable does not apply to the whole tenant

A variable applies to one process, not to the whole tenant: it is stored with a process key, and the platform only loads it when starting an instance of that process. If five processes need the "Support Email", the value has to be registered in all five — what you set on process A simply does not exist for process B.

What are they for?

Imagine a billing process that depends on the "Support Email" or on a "Standard Exchange Rate". Instead of hardcoding that value in the BPMN diagram — which forces you to publish a new version of the process every time it changes — create an support_email or exchange_rate variable in that process's configuration.

If the rate changes tomorrow, you edit the value on screen and new instances are born with it, with nothing to republish. Running instances keep the value they received: the variable is copied into the instance at start time, not re-read at every step.

Managing Variables

Variables live inside the process, not under a menu item of their own. Process Catalog is what gathers a process's configuration, and it is the way into all of it: variables, business key template, attachment policy, knowledge bases, agents and self-learning.

1. Go to Modeling → Process Catalog and open the process you want.
2. Switch to the Variables tab.
3. Enter an identifier that is unique within that process (no spaces, preferably snake_case) and the value.
4. Pick the type (STRING, INTEGER, DECIMAL, BOOLEAN, DATE) — it decides how the value reaches the process: an INTEGER arrives as a number, not as text.
5. Tick Secret when the value must not appear on screen or be returned by the public API that pre-fills forms.

Secret variables and AI agents

A variable marked Secret never reaches an AI agent as a value. In the agent's prompt, a {{my_key}} pointing at a secret variable renders as {{secret:my_key}} — the agent sees the name, never the content.

To use the credential in an API call, the agent writes that same handle in the HTTP request tool, for instance in a header:

Authorization: Bearer {{secret:my_key}}

The platform substitutes the real value at the last moment, on the way out to the network. The value does not enter the prompt, is not sent to the model provider, does not stay in the conversation history, and does not appear in the log — which records the method, the URL, the header names and the body length.

Write the prompt with the name, not the value: a prompt that says "authenticate with {{my_key}}" works — the call is made, the credential reaches its destination, and the model never sees the value.

On screen, a secret variable is displayed as ******** on the instance and task screens too, not only on the variables screen. Whoever opens the instance sees that the variable exists, never its content.

What this does not protect

An agent only reaches the hosts its own definition declares — see How far an agent may call in AI Agents. With no list declared the behaviour follows the installation's policy (AI_HTTP_TOOL_DEFAULT_POLICY), and internal network addresses are always blocked.

Using a secret in a process expression

A secret variable can be read at the moment of use, without being copied into the instance:

${secrets.get(execution, 'my_key')}

The value is fetched when needed, used, and stored nowhere — neither in the instance variables nor in the history.

The copy into the instance, and how to switch it off

For compatibility, secret variables are also copied into the instance's variables when a process starts — and Flowable stores instance variables in clear text, including in the history, which outlives the instance.

A new installation should run with SECRETS_INJECT_INTO_PROCESS_VARIABLES=false. The secret then never enters the instance, and expressions must use the form above. Every withheld variable is logged by name, so you can see what was held back.

Usage in Processes

The variable enters the instance under its plain name, exactly as you registered it. For a variable called my_variable, the BPMN expression is:

${my_variable}

${tenant.my_variable} does not resolve

Always use the plain name. The platform creates no object named tenant in the process scope, so ${tenant.my_variable} does not return the variable's value — it fails, or arrives empty in your flow, and the diagram is published without complaint.

If any point of your BPMN uses the prefix, replace ${tenant.x} with ${x} in all of them.