> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-mapping.md).

# Variable Mapping

Learn how to map variables between different scopes and components

Variable mapping allows you to map values between different variable scopes, pass data between phases and activities, and transform variable values.

***

### What you will learn from this topic <a href="#what-you-will-learn-from-this-topic" id="what-you-will-learn-from-this-topic"></a>

* Understand [what variable mapping is](#what-is-variable-mapping) and what it enables.
* How to follow the [variable flow](#variable-flow) from global to phase to activity variables.
* How to [use expressions instead of UI mapping](#using-expressions-instead-of-ui-mapping) to reference a global variable directly.
* How to [map and override activity inputs](#map-and-override-activity-inputs) in the Harness UI.
* How to configure [activity output mapping](#activity-output-mapping) to pass values between activities.
* How to use the [benefits](#benefits) of variable mapping to simplify input requirements.

***

### What variable mapping does <a href="#what-is-variable-mapping" id="what-is-variable-mapping"></a>

Variable mapping lets variables flow from global to phase to activity levels. This makes it easier for end users to understand the minimum inputs they must provide.

Variable mapping enables:

* **Scope Mapping**: Map between scopes (global → phase → activity)
* **Input Simplification**: Abstract pipeline inputs for users

### Variable flow <a href="#variable-flow" id="variable-flow"></a>

The variable mapping flow works as follows:

1. **Global Variables** are defined at the process level (typically 3-5 key inputs)
2. **Phase Variables** get mapped to global variables
   * Example: Phase variable `build_target` gets mapped to a global variable
3. **Activity Variables** (for pipeline activities) get mapped to phase variables
   * Phase variables, in turn, get mapped to global variables
   * Activity variables map to the pipeline for automated activities.
4. **Activity Outputs** can be captured from pipeline executions and used as inputs to later activities
   * Outputs from one activity become inputs to subsequent activities
   * This enables dynamic workflows where values generated in early phases flow to later phases

This flow makes it easier for end users to understand the minimum inputs they must provide.

### Using expressions instead of UI mapping <a href="#using-expressions-instead-of-ui-mapping" id="using-expressions-instead-of-ui-mapping"></a>

Instead of mapping a global variable to an activity input through the UI, you can reference it directly in the activity YAML:

```
<+releaseInput.global.<name>>
```

**Example:**

```yaml
activity:
  inputs:
    ENVIRONMENT: <+releaseInput.global.environment>
```

This resolves to the same value as mapping `ENVIRONMENT` to the global variable `environment` through the UI.

Go to [Supported Expressions](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/supported-expressions.md) to view the full expression reference.

### Map and override activity inputs <a href="#map-and-override-activity-inputs" id="map-and-override-activity-inputs"></a>

The following interactive walkthrough shows how to map an activity input to a phase or global variable, and how to override that mapping for an individual activity:

{% @arcade/embed url="<https://app.arcade.software/share/aAuZ54M5MDevVzoq0ZsW>" flowId="aAuZ54M5MDevVzoq0ZsW" %}

Go to [Default Values and Overrides](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/default-values-and-overrides.md) to understand how overrides apply at execution time.

### Activity output mapping <a href="#activity-output-mapping" id="activity-output-mapping"></a>

Activities can capture outputs from pipeline executions and make those values available to other activities. This is useful when you need to:

* Generate a dynamic value (version number, artifact URL) in one pipeline
* Use that value as input to multiple subsequent pipelines
* Maintain data consistency across different phases

**Configuring activity outputs**

In the source activity (the one generating the value), define outputs that capture pipeline output variables:

```yaml
activity:
  id: generate_version
  outputs:
    RELEASE_VERSION: <+pipeline.stages.version_stage.spec.execution.steps.generate_step.output.outputVariables.VERSION>
```

**Mapping outputs to inputs**

In the process input configuration, map the source activity's output to the destination activity's input:

```yaml
processInput:
  phases:
    - id: deployment
      activities:
        - id: deploy_activity
          inputs:
            VERSION: <+phase.generation.activity.generate_version.outputs.RELEASE_VERSION>
```

**Expression syntax for activity outputs**

To reference an activity output in a process input:

```
<+phase.<PHASE_ID>.activity.<ACTIVITY_ID>.outputs.<OUTPUT_NAME>>
```

**Example:**

* Phase ID: `build_phase`
* Activity ID: `build_app`
* Output name: `ARTIFACT_URL`
* Expression: `<+phase.build_phase.activity.build_app.outputs.ARTIFACT_URL>`

{% hint style="info" %}
**Phase dependencies**

When using activity outputs, ensure the destination phase depends on the source phase using `depends-on`. Without this dependency, phases may execute in parallel, and the output value will not be available when needed.
{% endhint %}

Go to [Passing Activity Outputs](/release-orchestration/troubleshooting-and-resources/release-orchestration-use-cases/passing-activity-outputs.md) to explore a complete walkthrough with examples.

### Benefits <a href="#benefits" id="benefits"></a>

**Simplified input requirements**

By mapping variables from global → phase → activity:

* Users only need to provide the key inputs (typically global variables)
* The rest are mapped within the process
* Pipeline inputs are abstracted, making the release easier to execute and its inputs easier to understand

**Example flow**

For a complex release process with 3 global variables:

* **Global Variable 1**: `release_version`
* **Global Variable 2**: `environment`
* **Global Variable 3**: `deployment_strategy`

These global variables will, in turn, be mapped to:

* **Phase variables**: Each phase can have variables that map to global variables
* **Activity variables**: Each activity (especially pipeline activities) can have variables that map to phase variables

When executing the release, you only need to provide these three global variables; the system handles the mapping to the phase and activity variables automatically.

### Related topics <a href="#related-topics" id="related-topics"></a>

* [Inputs and Variables Overview](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/overview.md)
* [Default Values and Overrides](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/default-values-and-overrides.md)
* [Global Variables](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-types/global-variables.md)

{% @harness-feedback/feedback %}