> 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/3.0/inputs-and-variables/variable-mapping.md).

# Variable Mapping

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

### What is Variable Mapping? <a href="#what-is-variable-mapping" id="what-is-variable-mapping"></a>

Variable mapping enables the flow of variables from global to phase to activity levels, creating an easy flow of variables and ease of use for end users to understand the minimum set of inputs they have to 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 in case of an automated activity
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 way, there is an easy flow of variables and ease of use for end users to understand the minimum set of inputs they have to provide.

### 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 <a href="#configuring-activity-outputs" id="configuring-activity-outputs"></a>

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 <a href="#mapping-outputs-to-inputs" id="mapping-outputs-to-inputs"></a>

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 <a href="#expression-syntax-for-activity-outputs" id="expression-syntax-for-activity-outputs"></a>

To reference an activity's 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 won't 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 <a href="#simplified-input-requirements" id="simplified-input-requirements"></a>

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 it easier for users who just want to execute and understand the inputs in a simple form

#### Example Flow <a href="#example-flow" id="example-flow"></a>

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, users only need to provide these 3 global variables, and the system handles the mapping to phase and activity variables automatically.

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

* [Inputs and Variables Overview](https://github.com/iKettles/harness-gitbook/tree/main/3k-release-management/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)