Wiring Parameters
In Conductor, various workflow and task parameters can be hard-coded or dynamically referenced from elsewhere (including its workflow parameters, prior task parameters, workflow variables, environment variables, and secrets). As long as it can be passed as a string, any workflow or task parameter can make use of a dynamic reference instead of a hard-coded value.
These dynamic references are formatted as dot-notation expressions, taking after JSONPath syntax.
Basic expression
All dynamic references are formatted as the following expression:
| Expression Component | Description |
|---|---|
| key | A string representing the parameter name for a workflow or task parameter. |
${...} | The root notation indicating that the variable will be dynamically replaced at runtime. |
| type | The type of reference. Supported values:
|
| jsonpath | JSONPath expression in dot-notation. The path is based on the reference type’s JSON object. |
Sample expressions
Depending on where the data is being referenced from, here is a non-exhaustive list of possible dynamic references:
| Dynamic References | Description |
|---|---|
${_taskReferenceName_.input} | References a prior task’s input object. Returns null if the task has not started when this reference was looked up. |
${_taskReferenceName_.output} | References a prior task’s output object. Returns null if the task has not started when this reference was looked up. |
${_taskReferenceName_.input._someKey_} | References a prior task’s input parameter someKey. Returns null if the task has not started when this reference was looked up. |
${_taskReferenceName_.output._someKey_} | References a prior task’s output parameter someKey. Returns null if the task has not started when this reference was looked up. |
${workflow.input} | References the workflow’s input object. |
${workflow.output} | References the workflow’s output object. |
${workflow.input._someKey_} | References the current workflow’s input parameter someKey. |
${workflow.output._someKey_} | References the current workflow’s output parameter someKey. |
${workflow.status} | References the current workflow’s status. Possible values: RUNNING, PAUSED, TIMED_OUT, TERMINATED, FAILED, or COMPLETED. |
${workflow.workflowId} | References the current workflow (execution) ID. |
${workflow.parentWorkflowId} | (Used in sub-workflows) References the parent workflow (execution) ID. |
${workflow.parentWorkflowTaskId} | (Used in sub-workflows) References the task execution ID for the Sub Workflow task in the parent workflow. |
${workflow.workflowType} | References the current workflow name. |
${workflow.version} | References the current workflow version. |
${workflow.createTime} | References the start time of the workflow execution. |
${workflow.correlationId} | References the current workflow’s correlation ID. |
${workflow.taskToDomain._domainName_} | References the workflow’s domain name that was invoked during its execution. |
${workflow.variables._someKey_} | References the workflow variable someKey, which has been set earlier in a Set Variable task. |
${workflow.env._someKey_} | References the environment variable someKey, which has been defined previously in the Conductor cluster. |
${workflow.secrets._someKey_} | References the secret someKey, which has been defined previously in the Conductor cluster. When inspected, the secret value will not be exposed and instead retain its reference value ${workflow.secrets.someKey}. During execution, if the workflow doesn't have permission to read the secret, it will fail with an error saying so. |
Examples
Here are some examples for using dynamic references in workflows.
Referencing workflow inputs
For the given workflow input:
{
"userID": 1,
"userName": "SAMPLE",
"userDetails": {
"country": "nestedValue",
"age": 50
}
}
You can reference these workflow inputs elsewhere using the following expressions:
{
"user": "${workflow.input.userName}",
"userAge": "${workflow.input.userDetails.age}"
}
At runtime, the parameters will be:
{
"user": "SAMPLE",
"userAge": 50
}
Referencing other task outputs
If a task previousTaskReference produced the following output:
{
"taxZone": "A",
"productDetails": {
"nestedKey1": "outputValue-1"
"nestedKey2": "outputValue-2"
}
}
You can reference these task outputs elsewhere using the following expressions:
{
"nextTaskInput1": "${previousTaskReference.output.taxZone}",
"nextTaskInput2": "${previousTaskReference.output.productDetails.nestedKey1}"
}
At runtime, the parameters will be:
{
"nextTaskInput1": "A",
"nextTaskInput2": "outputValue-1"
}
Referencing secrets
If a secret named api_key with the value Xxhhjiu0nbfdinvdHyj is stored in your Conductor cluster, you can reference it in a workflow using the following expression:
{
"auth": "${workflow.secrets.api_key}"
}
At runtime, the dynamic parameter auth resolves to the value of the secret api_key. This value will not be exposed in the workflow execution JSON, and users will only see the reference expression while inspecting the JSON object:
{
"auth": "${workflow.secrets.api_key}"
}
Referencing workflow variables
If a workflow variable is set using the Set Variable task:
{
"name": "Orkes"
}
The variable can be referenced in the same workflow using the following expression:
{
"user": "${workflow.variables.name}"
}
For example, the following workflow sets a variable in the first task and reads it in the second task.
{
"name": "set_and_read_variable_example",
"version": 1,
"schemaVersion": 2,
"tasks": [
{
"name": "set_user",
"taskReferenceName": "set_user_ref",
"type": "SET_VARIABLE",
"inputParameters": {
"name": "Orkes"
}
},
{
"name": "read_user",
"taskReferenceName": "read_user_ref",
"type": "INLINE",
"inputParameters": {
"evaluatorType": "graaljs",
"expression": "(function(){ return { greeting: 'Hello, ' + $.name }; })()",
"name": "${workflow.variables.name}"
}
}
]
}
At runtime, ${workflow.variables.name} in read_user_ref resolves to "Orkes", and the task outputs { "greeting": "Hello, Orkes" }.
Workflow variables cannot be re-referenced across workflows, even between a parent workflow and a sub-workflow.
Referencing environment variables
If an environment variable named location with the value US is stored in your Conductor cluster, you can reference it in a workflow using the following expression:
{
"place": "${workflow.env.location}"
}
At runtime, the parameters will be:
{
"place": "US"
}
Referencing data between parent workflow and sub-workflow
- From parent workflow
- From sub-workflow
To pass parameters from a parent workflow into its sub-workflow, you must declare them as input parameters for the Sub Workflow task.
Example
// parent workflow definition with task configuration
{
"createTime": 1733980872607,
"updateTime": 0,
"name": "testParent",
"description": "workflow with subworkflow",
"version": 1,
"tasks": [
{
"name": "get_item",
"taskReferenceName": "get_item_ref",
"inputParameters": {
"uri": "https://example.com/api",
"method": "GET",
"accept": "application/json",
"contentType": "application/json",
"encode": true
},
"type": "HTTP",
},
{
"name": "sub_workflow",
"taskReferenceName": "sub_workflow_ref",
"inputParameters": {
"user": "${workflow.variables.name}",
"item": "${previous_task_ref.output.item[0]}"
},
"type": "SUB_WORKFLOW",
"subWorkflowParam": {
"name": "testSub",
"version": 1
}
}
],
"inputParameters": [],
"outputParameters": {}
}
If needed, these inputs can then be set as workflow variables within the sub-workflow definition itself using a Set Variable task.
To pass parameters from a sub-workflow back to its parent workflow, you must pass them as the sub-workflow’s output parameters in the sub-workflow definition.
// sub-workflow definition
{
"createTime": 1726651838873,
"updateTime": 1733983507294,
"name": "testSub",
"description": "subworkflow for parent workflow",
"version": 1,
"tasks": [
{
"name": "get-user",
"taskReferenceName": "get-user_ref",
"inputParameters": {
"uri": "https://example.com/api",
"method": "GET",
"accept": "application/json",
"contentType": "application/json",
"encode": true
},
"type": "HTTP",
},
{
"name": "send-notification",
"taskReferenceName": "send-notification_ref",
"inputParameters": {
"uri": "https://example.com/api",
"method": "GET",
"accept": "application/json",
"contentType": "application/json",
"encode": true
},
"type": "HTTP",
}
],
"inputParameters": [],
"outputParameters": {
"location": "${get-user_ref.output.response.body.results[0].location.country}",
"isNotif": "${send-notification_ref.output}"
}
}
In the parent workflow, these sub-workflow outputs can be referenced using the expression format ${*sub_workflow_ref*.output.*someKey*}.
Troubleshooting
You can verify if the data was passed correctly by checking the input/output values of the task execution in Executions > Workflow. Common errors:
- If the reference expression is incorrectly formatted, the referencing parameter value may end up with the wrong data or a null value.
- If the reference parameter (such as a task output) has not been resolved at the point when it is referenced, the dynamic parameter will be null.