Masking Parameters
Masking parameters help protect sensitive data by preventing it from being exposed in workflow executions.
You can mask data in a workflow definition using the following parameters:
- _secrets
- _masked
- maskedFields
Masking sensitive data
When a value is masked, it is replaced with ***, ensuring that confidential information is hidden in workflow executions.
- Using _secrets parameter
- Using _masked parameter
- Using maskedFields parameter
For example:
{
"_secrets": {
"my-secret-key": "my-secret-value"
}
}
This is displayed in the workflow execution as:
{
"_secrets": "***"
}
For example:
{
"_masked": { "some": "data" }
}
This is displayed in the workflow execution as:
{
"_masked": "***"
}
- v5.1.18 and later
- v4.1.68 and later
Use the maskedFields parameter to specify which fields to mask during execution. Include the name of each field you want to mask as an element in the array.
For example:
// workflow definition
"maskedFields": [
"input1",
"input2"
]
In the workflow execution, the fields are displayed as:
{
"input1": "***",
"input2": "***"
}
Passing sensitive data between tasks
To pass sensitive data from one task's output to a subsequent task, nest the sensitive fields inside either the _secrets or _masked object in the receiving task’s input parameters as follows:
- Using _secrets parameter
- Using _masked parameter
{
"_secrets": {
"parameter": "${previousTaskRef.output.someOutputParameter}"
}
}
{
"_masked": {
"parameter": "${previousTaskRef.output.someOutputParameter}"
}
}
See the complete example in Passing sensitive data between tasks.
Masking secret references and secret values
The system masks fields that reference workflow secrets during execution. To reference a workflow secret, use the following syntax:
${workflow.secrets.<secretName>}
where <secretName> is the name of your secret. When the system resolves these expressions, it replaces their values with *** anywhere they appear, including workflow inputs, task inputs, task outputs, and the execution JSON.
For example,
"apiKey": "${workflow.secrets.my_api_key}"
is displayed during execution as
"apiKey": "***"
Resolved secret values are always masked, regardless of the context. This ensures that the underlying secret value is never exposed at any point in the workflow execution.
Secrets used within task expressions, such as in INLINE scripts or JSON JQ TRANSFORM expressions, are also masked during execution. When a secret is referenced or resolved inside an expression, its value is replaced with *** in task inputs, task outputs, and the execution details.
Workflow behavior with masked parameters
Behavior on restarting workflows with masked values: When a workflow with masked values reaches a terminal state and is removed from the primary execution:
- Values with the _masked parameter are retained during archiving. If the workflow is restarted, the original data will remain accessible.
- Values with the _secrets parameter are permanently replaced with *** during archiving. As a result, restarting the workflow might cause failures if any tasks rely on the masked data.
- Values within the maskedFields parameter are permanently replaced with *** during archiving. As a result, restarting the workflow might cause failures if any tasks rely on the masked data.
Examples
Using _secrets parameter
Consider a workflow with a task having an input masked using _secrets:
"inputParameters": {
"_secrets": "${workflow.input.somedata}"
}
Here’s the complete workflow definition:
{
"name": "workflow-with-secrets-param",
"description": "Sample workflow containing _secrets params",
"version": 1,
"tasks": [
{
"name": "simple",
"taskReferenceName": "simple_ref",
"inputParameters": {
"_secrets": "${workflow.input.somedata}"
},
"type": "SIMPLE"
}
],
"inputParameters": [
"somedata"
],
"schemaVersion": 2
}
When you run this workflow, the system masks the parameters in the execution results within the task input and the workflow input.

Using _masked parameter
Consider a workflow with a task having an input parameter masked using _masked:
"inputParameters": {
"_masked": "${workflow.input.somedata}"
}
Here’s the complete workflow definition:
{
"name": "workflow-with-masked-param",
"description": "Sample workflow containing _masked params",
"version": 1,
"tasks": [
{
"name": "simple",
"taskReferenceName": "simple_ref",
"inputParameters": {
"_masked": "${workflow.input.somedata}"
},
"type": "SIMPLE"
}
],
"inputParameters": [
"somedata"
],
"schemaVersion": 2
}
When you run this workflow, the system masks the parameters in the execution results within the task input and the workflow input.

Using maskedFields parameter
Consider a workflow definition with input parameters input1 and input2, and output parameter output1.
{
"name": "newMaskingParam",
"description": "Workflow for testing new masking params",
"version": 1,
"tasks": [
{
"name": "http",
"taskReferenceName": "http_ref",
"inputParameters": {
"uri": "https://orkes-api-tester.orkesconductor.com/api",
"method": "GET",
"accept": "application/json",
"contentType": "application/json",
"encode": true
},
"type": "HTTP"
}
],
"inputParameters": [
"input1",
"input2"
],
"outputParameters": {
"output1": "${http_ref.output}"
},
"schemaVersion": 2,
"maskedFields": [
"input1",
"input2"
]
}
In this example, both input fields are masked using:
"maskedFields": [
"input1",
"input2"
]
After running the execution, the values for input1 and input2 appear as *** in the workflow input, confirming that the masking is applied successfully.

Next, update the workflow definition to mask the input1 and output1 parameters:
//workflow definition
"maskedFields": [
"input1",
"output1"
]
When you run the execution, input1 and output1 are masked.

Passing sensitive data between tasks
Consider a workflow where a sensitive value from one task’s output needs to be passed to another task. To ensure the data remains masked, nest the parameter under _secrets in the receiving task’s input parameters.
{
"name": "workflow-pass-sensitive-data",
"description": "Workflow passing sensitive parameters between tasks",
"version": 1,
"tasks": [
{
"name": "simple-demo",
"taskReferenceName": "simple_demo_ref",
"type": "SIMPLE"
},
{
"name": "simple",
"taskReferenceName": "simple_ref",
"inputParameters": {
"_secrets": {
"parameter": "${simple_demo_ref.output.result}"
}
},
"type": "SIMPLE"
}
],
"schemaVersion": 2
}
You can also use the _masked parameter to mask the data in this scenario.
When you run this workflow, the system masks the sensitive data from simple_demo_ref.output.result in the execution results because you nested it under _secrets as the input parameter to the second task.

Masking secret references in workflow definitions
The following workflow calls an external payments API. The HTTP task sends an Authorization header that uses a secret stored as payment_api_token in the workflow secrets.
Store the API token as a secret in Conductor by navigating to Definitions > Secrets.

Next, create the workflow under Definitions > Workflow using the following definition:
{
"name": "charge_customer",
"description": "Charge a customer using an external payments API",
"version": 1,
"tasks": [
{
"name": "charge_payment",
"taskReferenceName": "charge_payment_ref",
"type": "HTTP",
"inputParameters": {
"uri": "https://orkes-api-tester.orkesconductor.com/api",
"method": "POST",
"headers": {
"Authorization": "Bearer ${workflow.secrets.payment_api_token}",
"Content-Type": "application/json"
},
"body": {
"customerId": "${workflow.input.customerId}",
"amount": "${workflow.input.amount}",
"currency": "USD"
}
}
}
],
"inputParameters": [
"customerId",
"amount"
],
"schemaVersion": 2
}
In this workflow, the Authorization header retrieves its value from the secret using "Authorization": "Bearer ${workflow.secrets.payment_api_token}".
During execution, the task input appears as:

The Authorization header value is masked because it resolves from ${workflow.secrets.payment_api_token}. Any occurrence of this secret value elsewhere is automatically masked as well.