> 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-activities/activity-types/automated-activities.md).

# Automated Activities

Learn about automated activities and how to configure pipeline inputs and outputs for them

Automated activities execute without human intervention, enabling efficient and consistent release execution. These activities run automatically when their dependencies are satisfied, allowing releases to progress through multiple phases without manual steps.

### What you will learn from this topic

* Understand [what an automated activity is](#what-are-automated-activities) and how [pipeline activities](#pipeline-activities) work
* How to [pass data to pipelines](#activity-inputs-passing-data-to-pipelines) using activity inputs
* How to [capture data from pipelines](#activity-outputs-capturing-data-from-pipelines) using activity outputs
* How to review an [example](#example-yaml) and the [best practices](#best-practices) for automated activities

### What are automated activities? <a href="#what-are-automated-activities" id="what-are-automated-activities"></a>

An automated activity is an activity that encapsulates a pipeline. It executes as part of a process when its dependencies are met, running the underlying pipeline automatically and handling the execution lifecycle without requiring human input.

### Pipeline activities <a href="#pipeline-activities" id="pipeline-activities"></a>

Pipeline activities are the primary type of automated activities used in release orchestration. These activities encapsulate pipelines by containing or referencing a Harness pipeline that performs the actual work. When the activity executes, activity variables are mapped to pipeline inputs, allowing you to pass configuration and data from the release orchestration layer down to the pipeline execution.

The system automatically tracks pipeline execution status, providing visibility into what is happening at each step. Pipeline outputs can be captured and used in subsequent activities, enabling you to pass data between them and build complex workflows in which later steps depend on results from earlier ones.

### Activity inputs: passing data to pipelines <a href="#activity-inputs-passing-data-to-pipelines" id="activity-inputs-passing-data-to-pipelines"></a>

Activity inputs are values that an activity receives from the release process (from global variables, phase variables, or outputs from previous activities). These inputs are then mapped to pipeline variables so the pipeline can use them during execution.

**Defining activity inputs**

Configure the `inputs` section in your activity to declare what values the activity expects:

```yaml
activity:
  id: deploy_activity
  name: Deploy Application
  inputs:
    # Declare activity inputs
    RELEASE_VERSION:
      description: "Version to deploy"
      type: string
      default: "v0.0.0"
    TARGET_ENVIRONMENT:
      description: "Environment to deploy to"
      type: string
      default: "staging"
  pipeline:
    pipeline: org/project/deploy_pipeline
    inputSet:
      variables:
        # Map activity inputs to pipeline variables
        - name: releaseVersion
          type: String
          value: <+activityInput.RELEASE_VERSION>
        - name: environment
          type: String
          value: <+activityInput.TARGET_ENVIRONMENT>
```

**How activity inputs work**

The data flow for activity inputs follows this pattern:

1. **Process Input defines the value**: When creating a release, you provide values in the process input (either directly as global variables or mapped from previous activity outputs)
2. **Activity receives the value**: The activity's `inputs` section receives the value
3. **Value maps to pipeline variable**: The `pipeline.inputSet.variables` section maps the activity input to the pipeline's variable using `<+activityInput.INPUT_NAME>`
4. **Pipeline executes with the value**: The pipeline receives the mapped value and uses it during execution

**Example flow:**

```
Process Input:
  RELEASE_VERSION: "v1.2.3"  (provided by user or from previous activity)
         ↓
Activity Input:
  RELEASE_VERSION: "v1.2.3"  (activity receives it)
         ↓
Pipeline Variable Mapping:
  releaseVersion = <+activityInput.RELEASE_VERSION>
         ↓
Pipeline Execution:
  Uses releaseVersion = "v1.2.3"
```

**Pipeline variable requirements**

For an activity input to be mappable to a pipeline, the pipeline must define the variable at the pipeline level with `value: <+input>`:

```yaml
pipeline:
  name: Deploy Application
  variables:
    - name: releaseVersion
      type: String
      value: <+input>  # Critical: Makes it available for mapping
```

Without `value: <+input>`, the variable will not appear in the activity's Pipeline Input Mapping interface.

{% hint style="success" %}
Always define pipeline variables at the pipeline level (not inside stages) and set them to `<+input>` to make them available for activity input mapping.
{% endhint %}

***

### Activity outputs: capturing data from pipelines <a href="#activity-outputs-capturing-data-from-pipelines" id="activity-outputs-capturing-data-from-pipelines"></a>

Pipeline activities can capture output variables from pipeline executions. This allows you to extract dynamic values generated during pipeline execution (such as version numbers, artifact URLs, or configuration IDs) and use them as inputs to later activities.

**Defining activity outputs**

Configure the `outputs` section in your activity to capture pipeline output variables:

```yaml
activity:
  id: build_activity
  name: Build Application
  outputs:
    # Capture output variable from pipeline
    ARTIFACT_VERSION: <+pipeline.stages.build_stage.spec.execution.steps.build_step.output.outputVariables.VERSION>
    ARTIFACT_URL: <+pipeline.stages.build_stage.spec.execution.steps.publish_step.output.outputVariables.ARTIFACT_URL>
  pipeline:
    pipeline: org/project/build_pipeline
```

**Output expression syntax**

The expression to capture a pipeline output variable follows this structure:

```
<+pipeline.stages.<STAGE_ID>.spec.execution.steps.<STEP_ID>.output.outputVariables.<VAR_NAME>>
```

**Example:**

* Stage ID: `build_stage`
* Step ID: `build_step`
* Output variable name: `VERSION`
* Expression: `<+pipeline.stages.build_stage.spec.execution.steps.build_step.output.outputVariables.VERSION>`

**Pipeline output variable requirements**

For an output variable to be captured, the pipeline step must define it in the `outputVariables` section:

```yaml
- step:
    type: ShellScript
    name: Build
    spec:
      script: |
        VERSION="v1.2.3"
        export VERSION="$VERSION"
      outputVariables:
        - name: VERSION
          type: String
          value: VERSION
```

{% hint style="success" %}
Test your pipeline manually before creating the activity to verify that output variables are generated correctly. Check the step's Output tab in the pipeline execution view.
{% endhint %}

### Using activity outputs in later activities <a href="#using-activity-outputs-in-later-activities" id="using-activity-outputs-in-later-activities"></a>

Once an activity captures outputs, those values can be passed to subsequent activities through [process input configuration](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-mapping.md).

**Example workflow:**

1. Build activity outputs: `ARTIFACT_VERSION = "v1.2.3"`
2. Deploy activity expects input: `VERSION`
3. Process input maps: `VERSION: <+phase.build.activity.build_app.outputs.ARTIFACT_VERSION>`

For more information, see [Passing Activity Outputs](/release-orchestration/troubleshooting-and-resources/release-orchestration-use-cases/passing-activity-outputs.md).

### Example (YAML) <a href="#example-yaml" id="example-yaml"></a>

This example shows an activity within a process that references a pipeline. The activity is defined within a phase and references a specific pipeline that executes when the activity runs.

```yaml
phase:
  id: deploy_phase
  name: Deploy to Staging1 Phase
  activities:
    - activity: WaitingActivity
      id: WaitingActivity
      name: WaitingActivity
      depends-on: []
      data:
        pipeline:
          pipeline: default/MyProject/MyPipeline
          inputSet: {}
```

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

**Idempotency**

Design activities to be idempotent so they are safe to retry without causing problems. Idempotent activities produce no side effects when repeated and deliver consistent results regardless of how many times they are executed.

This is especially important in release orchestration, where activities might be retried due to transient failures or manual intervention.

**Error handling**

Implement error handling that provides clear error messages when things go wrong. Use appropriate retry strategies for transient failures, and ensure failure notifications are sent to the right people so issues can be addressed quickly.

Good error handling makes debugging easier and helps releases recover from problems automatically when possible.

**Logging**

Ensure proper logging throughout the activity execution, so you have visibility into what happened. Execution logs should capture the flow of operations, and error details should provide enough context to diagnose issues.

Performance metrics help you understand how long activities take and identify bottlenecks.

**Testing**

Test automated activities thoroughly before using them in production releases. Unit testing verifies individual components work correctly, integration testing ensures activities work well with the rest of the release process, and failure scenario testing helps you understand how activities behave when things go wrong.

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

* [Activities Overview](/release-orchestration/use-release-orchestration/release-orchestration-activities/activities-overview.md)
* [Manual Activities](/release-orchestration/use-release-orchestration/release-orchestration-activities/activity-types/manual-activities.md)
* [Activity Dependencies](/release-orchestration/use-release-orchestration/release-orchestration-activities/activities-overview.md#activity-dependencies-and-execution-order)

{% @harness-feedback/feedback %}