> 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-types/phase-variables.md).

# Phase Variables

Learn about phase variables and how to scope variables to phases

Phase variables are inputs shared across all activities within a phase. They provide an intermediate scope between global and activity variables, making them ideal for configuration that applies to all activities within a specific phase but may differ between phases.

### What are phase variables? <a href="#what-are-phase-variables" id="what-are-phase-variables"></a>

Phase variables are scoped to the phase in which they are defined, making them available only within that phase. They can inherit values from global variables if those values are not overridden at the phase level.

Each phase can have its own unique set of variables, which are isolated from other phases, providing clear boundaries for phase-specific configuration.

### Examples <a href="#examples" id="examples"></a>

Phase variables work well for values that need to be consistent across all activities within a phase but may differ between phases. Common examples include the environment name for the phase, such as "staging" or "prod", which all activities in that phase will use.

A region for a wave deployment, like "us-east-1" or "eu-west-1", is another good use case. A common change ticket ID that applies to all activities in a "Change Management" phase is often defined as a phase variable.

### Characteristics <a href="#characteristics" id="characteristics"></a>

Phase variables are scoped to the phase, meaning all activities within that phase can reference them via expressions. This scoping allows you to avoid duplicating the same value across activities, reducing configuration overhead and ensuring consistency.

These variables are evaluated by the same expression engine used by the pipeline service, ensuring consistent evaluation behavior across all activities.

### Conceptual example <a href="#conceptual-example" id="conceptual-example"></a>

Consider a "Staging Deployment" phase with a phase variable `env = "staging"`. All activities within this phase can reference this variable. For example, the "Deploy Service A" activity uses `env` to select the environment, and the "Run smoke tests" activity uses `env` to choose the test environment.

This ensures all activities in the phase use the same environment value without each activity needing to define it separately.

### Defining phase variables <a href="#defining-phase-variables" id="defining-phase-variables"></a>

Phase variables are typically mapped from global variables, so you provide only the minimum set of inputs at execution time. This mapping approach reduces the number of values you need to provide while still allowing phase-specific customization.

For example, a global variable might define a base environment name, and phase variables can derive specific environment values from it.

### Using phase variables <a href="#using-phase-variables" id="using-phase-variables"></a>

**Variable resolution**

The system resolves variables in this order: phase variables, then global variables, and finally process defaults.

This resolution order ensures that phase-specific values take precedence over global values, allowing you to override global defaults at the phase level when needed.

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

**Phase isolation**

Variables are isolated per phase. Phase A has its own variables, and Phase B has its own variables. Variables are not shared between phases, providing clear boundaries for variable scope.

This isolation means you can have different values for the same variable name in different phases without conflicts.

### Best practices <a href="#best-practices" id="best-practices"></a>

**Appropriate scope**

Use phase variables for a variable needed only within a single phase, for phase-specific configuration or isolated phase logic, or for phase-specific defaults that differ from global defaults.

This helps keep your variable hierarchy clean and makes it easier to understand which values apply where.

**Clear naming**

Use descriptive names that make it clear what the variable represents and how it is used. For example, use `deployment_max_retries` rather than a generic name like `retries`.

Good naming becomes especially important when you have multiple phases that might use similar but different variables.

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

For more information, see the following topics:

* [Inputs and Variables Overview](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/overview.md)
* [Global Variables](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-types/global-variables.md)
* [Activity Variables](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-types/activity-variables.md)
* [Variable Mapping](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-mapping.md)

{% @harness-feedback/feedback %}