Skip to main content

Passing Inputs to Tasks in Conductor

When you start a Conductor workflow, you can pass inputs to the workflow - which can be used as parameters for various steps in the workflow. As the tasks progress in a workflow - each task will create its own outputs. So how can this data from previous tasks be used in the steps succeeding it? In Conductor, data can be passed to a task in different ways, such as from workflow inputs/outputs, prior task inputs/outputs, variables, and secrets.

Let’s take a look at how to define this.


The task inputs are evaluated using the following expression:

"variableName" : "${type.subtype.jsonpath}"

Let’s break down this expression:

variableNameA string that represents the variable name you want to assign this expression output.
${...}A notation that indicates the variable that would be dynamically replaced at run time.
typeOne of the following options:
workflow : Refers to the workflow instance
task_reference_name : Refers to a task in a workflow by its reference name
subtypeOne of the following options:
input : Refers to the input of the type = (workflow or task-ref)
output : Refers to the output of the type = (workflow or task-ref)
secrets : Refers to secrets in the system, accessed with type = workflow
variables : Refers to variables of the workflow, accessed with type = workflow
jsonpathJSONPath expression (look for examples below). If we are referring to variables/secrets, this will be the variable/secret name.

Sample Expressions

If the task inputs are taken from workflow inputs,

"key": "${workflow.input.somekey}"

This expression defines a property called key, with a value derived from the input parameter somekey provided to the current workflow.

Detailed Examples

Task Inputs referred from Workflow Inputs​​
When we start a workflow, we can provide inputs to the workflow in a JSON format like this:

"workflowInputNumberExample": 1,
"workflowInputTextExample": "SAMPLE",
"workflowInputJsonExample": {
"nestedKey": "nestedValue"

We can refer to these values as inputs to the task using the following expression:

"taskInput1Key": "${workflow.input.worfklowInputNumberExample}",
"taskInput2Key": "${workflow.input.workflowInputJsonExample.nestedKey}"

On evaluating the first expression,

    "taskInput1Key": "${workflow.input.workflowInputNumberExample}"
  • "${workflow.input.workflowInputNumberExample}"- Refers to the workflow input parameter workflowInputNumberExample.

In the workflow input, the value of workflowInputNumberExample is 1, so the value of taskInput1Key in this example is also 1.

Similarly, evaluating this expression "taskInput2Key": "${workflow.input.workflowInputJsonExample.nestedKey}" would result in "taskInput2Key": "nestedValue". So, the input to the task referred from the workflow input looks like this:

"taskInput1Key": 1,
"taskInput2Key": "nestedValue"
Task Inputs referred from other Task Outputs​​​

Let’s assume that a task with the task reference name previousTaskReference produced the following output:

"taskOutputKey1": "outputValue",
"taskOutputKey2": {
"nestedKey1": "outputValue-1"

We can refer to these values as inputs to our new task using the following expression:

"taskInput1Key": "${previousTaskReference.output.taskOutputKey1}",
"taskInput2Key": "${previousTaskReference.output.taskOutputKey2.nestedKey1}"

The above expression can be evaluated using the same mechanism explained above, and finally, the task will receive the following inputs from the previous task output:

"taskInput1Key": "outputValue",
"taskInput2Key": "outputValue-1"

The expression format is based on JSON Path and you can construct complex input params based on the syntax.

Task Inputs referred from Secrets​​

Let’s assume that a secret named “api_key” is stored on your Conductor console, and you need to refer to this secret. The sample expression can look like this:

"taskInputKey": "${workflow.secrets.api_key}"

If the api_key has value Xxhhjiu0nbfdinvdHyj. Then the task input becomes:

"taskInputKey": "Xxhhjiu0nbfdinvdHyj"

Referring to task inputs using the secret functionality ensures that your secrets are not exposed in the workflow definitions; instead, it takes the value dynamically while executing the workflow.

Task Inputs referred from Variables​

If the variable name is stored via the Set Variable task, the JSON looks like this:

     "name": "set_variable_task_anmz4_ref",
"taskReferenceName": "set_variable_task_anmz4_ref",
"inputParameters": {
"name": "Orkes"
"type": "SET_VARIABLE",

So, here the variable name is set to Orkes. We can refer to this variable in the same workflow as follows:

    "variable_name": "${}"

This results in "variable_name": "Orkes".

Through Task Input Templates

While creating task definitions, you can define the task input templates. These values will be supplied to each execution of the task and can be overridden within the workflow. It means that the parameters are included in the task definition, and whenever the task is used in a workflow, these parameters would be included by default in the workflow.

While creating a task definition, you can define the task input template as follows:

Using UI forms:

Task input template in task definition

Using JSON code:

"name": "test-task",
"description": "Edit or extend this sample task. Set the task name to get started",
"retryCount": 3,
"timeoutSeconds": 3600,
"inputKeys": [],
"outputKeys": [],
"inputTemplate": {
"key": "value"
"ownerEmail": ""

Adding this task to the workflow definition would already include the parameters supplied via the input task template.

Workflow definition with task input template supplied already

These values can also be overridden by supplying input parameters to the task in the workflow definition.

Overriding task input template parameters from Workflow definition

Here, initially, some “key” were supplied through input templates. Now, when the same “key” was provided as input parameters in the workflow definition, the values got overridden.


You cannot view the input templates in the workflow definition JSON code as they are part of only task definitions. But, on clicking the task, you can view the input templates supplied from the UI.


Why do I get JSONPath error messages?

JSONPath error messages occur when there is an issue with the JSON expression due to incorrect syntax or an invalid path.

What happens when an incorrect task reference name is provided in the JSON expression?

The task reference names should be unique in a workflow. You may get errors while executing the workflow if you have provided an incorrect task reference name.

What happens if my JSONPath expression is incorrect?

Incorrect JSONPath expressions may result in a null value instead of the expected output.

How can I check if the data was passed correctly?

You can verify if the data was passed correctly by checking the input/output fields of the task.

Can I hard code inputs?

Yes, you can provide hard-coded inputs. This becomes useful when you have a reusable task with configurable options that can be applied in different workflow contexts.

When should I use Set Variables (Global Variables)?

Set Variable can be used when you need to store a variable and use it later across different tasks & workflows.