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

# Activity Variables

Learn about activity variables and how to scope variables to activities

Activity variables are inputs that are specific to a particular activity instance. They provide the most granular configuration within the variable hierarchy, allowing you to customize individual activities without affecting others.

This isolation makes them ideal for settings that are unique to a single activity's execution, such as deployment targets, notification channels, or activity-specific feature flags.

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

Activity variables are scoped to the activity where they are defined, making them available only within that specific activity instance. They can inherit values from phase or global variables if those values are not overridden at the activity level.

Each activity can have its own unique configuration, even when multiple activities use the same template. This makes activity variables the most specific variable scope available, providing the narrowest scope in the variable hierarchy.

### Activity inputs vs activity outputs <a href="#activity-inputs-vs-activity-outputs" id="activity-inputs-vs-activity-outputs"></a>

Activities work with two types of variables:

**Activity inputs**

Activity inputs are values that the activity receives from external sources (such as process inputs, global variables, or phase variables). These inputs are then mapped to pipeline variables for automated activities.

**Example**:

```yaml
activity:
  inputs:
    DEPLOYMENT_VERSION:
      type: string
      default: "v1.0.0"
  pipeline:
    inputSet:
      variables:
        - name: version
          value: <+activityInput.DEPLOYMENT_VERSION>
```

The expression `<+activityInput.DEPLOYMENT_VERSION>` references the activity's input and passes it to the pipeline.

An activity input can also reference a global or phase variable directly, instead of mapping it through the UI:

```yaml
activity:
  inputs:
    DEPLOYMENT_VERSION: <+releaseInput.global.deployment_version>
```

Go to [Variable Mapping](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-mapping.md#using-expressions-instead-of-ui-mapping) to view more examples.

**Activity outputs**

Activity outputs are values that the activity captures from pipeline execution and makes available to other activities. These allow data to flow from one activity to subsequent activities.

**Example**:

```yaml
activity:
  outputs:
    BUILD_VERSION: <+pipeline.stages.build.spec.execution.steps.version_step.output.outputVariables.VERSION>
```

This captures the `VERSION` output variable from the pipeline and makes it available as `BUILD_VERSION` to other activities.

{% hint style="success" %}
Activity outputs enable dynamic workflows in which values generated in earlier activities (such as version numbers or artifact URLs) flow automatically to later activities. Go to [Passing Activity Outputs](/release-orchestration/troubleshooting-and-resources/release-orchestration-use-cases/passing-activity-outputs.md) to see a complete example.
{% endhint %}

***

### Expression syntax <a href="#expression-syntax" id="expression-syntax"></a>

Use these expressions to reference activity inputs and outputs:

**Activity input expression**

Reference an activity input within the activity's pipeline mapping:

```
<+activityInput.<name>>
```

**Example**: `<+activityInput.environment>` references the activity's `environment` input.

**Activity output expression**

Reference an activity output in the process input to pass values to other activities:

```
<+process.<phaseId>.<activityId>.output.<name>>
```

**Example**: `<+process.phase1.activityA.output.pipelineName>` references the `pipelineName` output from `activityA` in `phase1`.

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

***

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

Activity variables are useful for configuration that is specific to a single activity's execution. Common examples include the image tag or artifact ID to deploy, the Jira project or issue type to be updated for a release, or the Slack channel to notify for this activity only.

A feature flag name that identifies the functionality it enables is another common use case.

### Features <a href="#features" id="features"></a>

Each activity variable supports default and static values. When a variable is created, default values can be assigned to the variable. When a default value is assigned to the variable, the activity always gets executed with that value. When the value needs to be overridden, you can provide it at runtime.

### Usage <a href="#usage" id="usage"></a>

Activity variables allow you to customize the behavior of a reusable activity template per phase or per release. This means you can use the same activity template multiple times with different configurations, tailoring each instance to its specific context.

They also let you override default values defined in the template when needed, providing flexibility to adapt to different execution scenarios without modifying the underlying template.

### Defaults and overrides <a href="#defaults-and-overrides" id="defaults-and-overrides"></a>

Activity variables can have default values assigned when they are created, which provides a baseline configuration for the activity. These defaults ensure the activity can execute successfully even if no specific values are provided during release execution.

You can override them at runtime as needed, allowing you to adapt to different scenarios or requirements without changing the activity definition.

**Variable resolution**

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

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

**Activity isolation**

Variables are isolated per activity. Activity A has its own variables, and Activity B has its own variables. Variables are not shared between activities, providing clear boundaries for variable scope.

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

**Appropriate scope**

Use activity variables for a variable needed only within an activity, for activity-specific configuration or isolated activity logic, or for activity-specific defaults.

**Clear naming**

Use descriptive names that make it clear what the variable represents. For example, use `service_deployment_port` rather than a generic name like `port`.

### 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)
* [Phase Variables](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-types/phase-variables.md)
* [Variable Mapping](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-mapping.md)

{% @harness-feedback/feedback %}