Skip to content

Masking Parameters

5-minute path

Store long-lived credentials as secrets, reference them with ${workflow.secrets.<secretName>}, and use _masked, _secrets, or maskedFields for sensitive runtime values.

Masking sensitive data

When a value is masked, it is replaced with ***, hiding confidential information in workflow executions.

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": "***"
}

Note

Available since 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:

{
  "_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.

Note

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

Masking affects restart and archive behavior:

Mechanism Restart/archive behavior
_masked Retained during archiving, so restarts can still use the original value.
_secrets Permanently replaced with *** during archiving. Restarting may fail if downstream tasks still require the original value.
maskedFields Permanently replaced with *** during archiving. Restarting may fail if the field is required later.

For long-running or restartable workflows, prefer workflow secrets for durable credentials and _masked for runtime values that a restart may need.

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 the workflow, the system masks the parameters in the execution results within the task input and the workflow input.

Masked inputs using the _secrets parameter

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 the workflow, the system masks the parameters in the execution results within the task input and the workflow input.

Masked inputs using the masked parameter

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.

Execution with fields masked using maskedfields parameter

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.

Execution with fields masked using maskedfields parameter

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
}

Note

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 it is nested under _secrets as the input parameter to the second task.

Passing data between tasks

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.

Secret stored in Orkes Conductor

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:

Secret masked in Orkes Conductor

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.