Pass Global Parameters Across Workflow Steps (2026)

You can pass global parameters across workflow steps by defining them in the workflow’s parameters block and referencing them using the {{ .workflow.parameters.<param_name> }} syntax.

Let’s see this in action. Imagine a workflow that first fetches a list of servers and then, for each server, runs a script. We want to pass a region parameter to both steps.

# workflow.yaml
version: 1.0

parameters:
  region:
    default: "us-east-1"
    description: "The AWS region to operate in."

steps:
  - name: fetch_servers
    template:
      name: fetch_servers_template
      parameters:

        region: "{{ .workflow.parameters.region }}"


  - name: run_script_on_servers
    template:
      name: run_script_template
      parameters:

        region: "{{ .workflow.parameters.region }}"


        server_list: "{{ .steps.fetch_servers.outputs.servers }}" # Assuming fetch_servers outputs a list of servers


templates:
  fetch_servers_template:
    script: |

      echo "Fetching servers in region: {{ .parameters.region }}"

      # In a real scenario, this would call an API or query a service
      # For demonstration, we'll just output a dummy list

      echo '{"servers": ["server-1", "server-2"]}' > "{{output.servers}}"

    outputs:
      servers:

        path: "{{ .outputs.servers }}"


  run_script_template:
    script: |

      echo "Running script on servers in region: {{ .parameters.region }}"


      for server in $(echo "{{ .parameters.server_list }}" | jq -r '.servers[]'); do

        echo "  - Running on $server"
        # In a real scenario, this would execute a script on the server
      done

In this example, the region parameter is defined at the workflow level. The fetch_servers step and the run_script_on_servers step both reference this global parameter using {{ .workflow.parameters.region }}. This makes the region value available to any step within the workflow.

The fetch_servers step takes the region parameter and uses it to determine which servers to fetch. It then outputs a list of servers. The run_script_on_servers step also receives the region parameter and the list of servers from the previous step. This demonstrates how parameters can be passed down through sequential steps.

When you run this workflow, you can override the default region by providing it on the command line:

argo submit workflow.yaml --set-parameter region="eu-west-2"

This command will execute the workflow, and both the fetch_servers and run_script_on_servers steps will use eu-west-2 as their region. If you don’t provide the --set-parameter flag, the default us-east-1 will be used.

The mental model here is that the workflow.parameters block acts as a shared, read-only context for all steps. Each step can access these parameters by their name. If a step needs to pass its own output to another step, it does so via the outputs mechanism, which is distinct from the global parameters. However, the value of a global parameter can be used to configure how a step produces its outputs, or what it does with them.

A common pattern is to use workflow parameters for configuration that applies broadly, like environment names, cloud provider regions, or version numbers. This avoids repeating the same configuration values across multiple steps or templates, making the workflow definition cleaner and easier to maintain. If you need to change the region, you only have to update it in one place: the parameters block or the command-line override.

What’s often overlooked is how deeply nested parameters can be accessed. If you had a parameter that was a JSON object, like config: { api_key: "xyz", timeout: 30 }, you could access api_key as {{ .workflow.parameters.config.api_key }}. This allows for complex, structured configuration to be managed globally.

When you use {{ .workflow.parameters.<param_name> }} within a template’s parameters block, you’re essentially creating a bridge. The workflow-level parameter’s value is being injected into the template’s parameter namespace for that specific step instance. This is how the global context flows down to the individual step’s execution environment.

The next concept you’ll likely encounter is managing conditional execution based on these global parameters, allowing parts of your workflow to run only when certain parameter values are met.