> 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/troubleshooting-and-resources/release-orchestration-troubleshooting/activity-output-troubleshooting.md).

# Troubleshooting Activity Outputs and Input Mapping

Troubleshoot common issues with passing data between activities.

This topic covers common issues when passing activity outputs to later activities as inputs.

<details>

<summary>Pipeline variables do not appear in activity input mapping</summary>

**Symptom**

When configuring an activity's Pipeline Input Mapping, the dropdown or list shows "No Data" or does not display the pipeline's input variables.

**Cause**

Pipeline variables are not defined at the pipeline level, or they are not marked as runtime inputs.

**Solution**

1. **Open the destination pipeline** (the one that should receive inputs).
2. **Add or edit pipeline-level variables:**
   * In the UI: select **Variables** in the right panel or under Advanced settings.
   * In YAML: add a `variables` section at the pipeline root level.
3. **Set the variable value to `<+input>`:**

   ```yaml
   pipeline:
     name: Deploy Application
     variables:
       - name: deploymentVersion
         type: String
         value: <+input>  # Critical: Makes it available for mapping
   ```
4. **Save the pipeline.**
5. **Return to the activity** and refresh the Pipeline Input Mapping tab.

{% hint style="warning" %}
The `value: <+input>` is required. Without it, the variable does not appear in the activity's Pipeline Input Mapping interface, even if the variable exists in the pipeline.
{% endhint %}

</details>

<details>

<summary>Activity receives the default value instead of the generated value</summary>

**Symptom**

The destination activity receives its default input value (for example, `v0.0.0`) instead of the dynamically generated value from the source activity.

**Cause 1: Missing phase dependency**

The destination phase runs in parallel with the source phase, so the output value is not available yet.

Solution:

1. Edit the process YAML.
2. Find the destination phase.
3. Add `depends-on` configuration:

   ```yaml
   - phase:
       id: deployment
       name: Deployment
       depends-on:
         - version_generation  # Phase that generates the value
   ```
4. Save the process.

**Cause 2: Incorrect expression in process input**

The expression path does not match the actual phase ID, activity ID, or output name.

Solution:

1. Verify the expression syntax:

   ```
   <+phase.<PHASE_ID>.activity.<ACTIVITY_ID>.outputs.<OUTPUT_NAME>>
   ```
2. Check that the IDs match your process configuration (case-sensitive).
3. Common mistakes:
   * Using the phase name instead of the phase ID: `<+phase.Version Generation...>` (incorrect).
   * Correct: `<+phase.version_generation...>`.
   * Missing `outputs` in the path: `<+phase.x.activity.y.OUTPUT>` (incorrect).
   * Correct: `<+phase.x.activity.y.outputs.OUTPUT>`.

**Cause 3: Activity output not configured**

The source activity does not have an `outputs` section, so the value is not captured.

Solution:

1. Edit the source activity.
2. Add the `outputs` section:

   ```yaml
   activity:
     outputs:
       RELEASE_VERSION: <+pipeline.stages.STAGE.spec.execution.steps.STEP.output.outputVariables.VERSION>
   ```
3. Verify the pipeline expression path matches your pipeline structure.

</details>

<details>

<summary>Both phases run simultaneously</summary>

**Symptom**

The source phase and destination phase start executing at the same time, rather than the destination phase waiting for the source phase to complete.

**Cause**

No dependency is configured between the phases.

**Solution**

Add a phase dependency:

```yaml
phases:
  - phase:
      id: source_phase
      name: Source Phase
      depends-on: []

  - phase:
      id: destination_phase
      name: Destination Phase
      depends-on:
        - source_phase  # Add this
```

{% hint style="info" %}
Phase dependencies ensure correct execution order. Without them, Release Orchestration executes phases in parallel to optimize execution time.
{% endhint %}

</details>

<details>

<summary>Expression shows unresolved in activity input</summary>

**Symptom**

The activity's input displays the raw expression (for example, `<+phase.build.activity.gen.outputs.VERSION>`) instead of the actual value.

**Cause**

The expression was evaluated before the source activity completed, typically due to parallel execution or missing dependencies.

**Solution**

1. **Verify phase dependencies:** confirm `depends-on` is configured correctly.
2. **Check execution order:** review the release execution and confirm the source phase completes before the destination phase starts.
3. **Verify the expression is correct:** test by manually running the release and checking if the value appears after the source phase completes.

</details>

<details>

<summary>Activity output shows no values</summary>

**Symptom**

The source activity's Outputs tab shows no values, even though the pipeline executed successfully.

**Cause 1: Pipeline output variable not defined**

The pipeline step does not have an `outputVariables` section.

Solution:

1. Edit the source pipeline.
2. Find the step that generates the value.
3. Add `outputVariables`:

   ```yaml
   - step:
       type: ShellScript
       spec:
         script: |
           VERSION="v1.2.3"
           export VERSION="$VERSION"
         outputVariables:
           - name: VERSION
             type: String
             value: VERSION  # Environment variable name
   ```
4. Save and test the pipeline.

**Cause 2: Incorrect expression path in the activity**

The activity's output expression does not match the pipeline structure.

Solution:

1. Run the pipeline manually.
2. Find the output variable in the step's Outputs tab.
3. Build the correct expression:

   ```
   <+pipeline.stages.<STAGE_ID>.spec.execution.steps.<STEP_ID>.output.outputVariables.<VAR_NAME>>
   ```
4. Update the activity's outputs section with the correct expression.

**Cause 3: Variable not exported in script**

The shell script does not export the variable for Harness to capture.

Solution: Ensure the script exports the variable.

```bash
#!/bin/bash
VERSION="v1.2.3"
echo "Generated: $VERSION"

# Export the variable so Harness can capture it
export VERSION="$VERSION"
```

</details>

<details>

<summary>Pipeline input mapping shows the wrong variable type</summary>

**Symptom**

The activity's Pipeline Input Mapping shows a variable with the wrong type or format.

**Cause**

The pipeline variable type does not match the activity input type.

**Solution**

Ensure type consistency.

Activity input:

```yaml
inputs:
  DEPLOYMENT_VERSION:
    type: string
```

Pipeline variable:

```yaml
variables:
  - name: version
    type: String  # Must match
    value: <+input>
```

</details>

<details>

<summary>Expression evaluates to an empty string</summary>

**Symptom**

The destination activity receives an empty string instead of the expected value.

**Possible causes and solutions**

**1. The source pipeline did not generate output**

* Check source pipeline logs.
* Verify the step actually exports the variable.
* Test the pipeline manually.

**2. Wrong output variable name**

* Check the pipeline's outputVariables name.
* Ensure the activity output expression uses the correct name.
* Variable names are case-sensitive.

**3. Step failed before exporting**

* Check if the pipeline step completed successfully.
* Verify exports happen before any exit statements.
* Check for early returns or errors.

</details>

## Testing and debugging tips

Use the following checks to isolate issues with activity output and input mapping.

**Test pipelines individually**

Before creating activities:

1. Run the source pipeline manually.
2. Verify output variables appear in the step's Outputs tab.
3. Note the exact variable names.
4. Run the destination pipeline manually with a test value.
5. Verify the pipeline uses the input correctly.

**Test activities without dependencies**

Create a test release:

1. Set the source activity to run alone.
2. Check its outputs after execution.
3. Manually provide those output values to the destination activity.
4. Verify the destination activity accepts and uses the values.

**Check expression resolution**

Use the expression, evaluator:

1. In the pipeline execution view, find the expression evaluator.
2. Test your activity output expression:

   ```
   <+phase.source.activity.gen.outputs.VERSION>
   ```
3. Verify it resolves to the expected value.

**Review execution timeline**

In the release execution view:

1. Check the start and end times of each phase.
2. Verify that the source phase completes before the destination phase starts.
3. If timing is wrong, check phase dependencies.

**Enable debug logging**

In pipeline steps, add debug logging:

```bash
#!/bin/bash
set -x  # Enable debug mode

echo "Generating version..."
VERSION="v1.2.3"
echo "VERSION=$VERSION"

export VERSION="$VERSION"
echo "Exported VERSION"
```

## Common expression mistakes

The following table lists common expression mistakes and their corrections.

| Wrong                           | Correct                                 | Issue                   |
| ------------------------------- | --------------------------------------- | ----------------------- |
| `<+phase.Build.activity...>`    | `<+phase.build.activity...>`            | Phase names vs IDs      |
| `<+phase.x.activity.y.VERSION>` | `<+phase.x.activity.y.outputs.VERSION>` | Missing `outputs`       |
| `<+activityInput.version>`      | `<+activityInput.VERSION>`              | Case sensitivity        |
| `<+pipeline.stage.spec...>`     | `<+pipeline.stages.stage.spec...>`      | Missing plural `stages` |

## Prevention checklist

Confirm the following before executing a release with activity outputs:

* [ ] The source pipeline is `outputVariables` defined in the relevant step.
* [ ] Source pipeline tested manually, outputs appear correctly.
* [ ] Source activity has a `outputs` section with the correct expression.
* [ ] The destination pipeline has pipeline-level `variables` with `value: <+input>`.
* [ ] The destination pipeline was tested manually with a test input value.
* [ ] Destination activity has an `inputs` section defined.
* [ ] Destination activity has Pipeline Input Mapping configured.
* [ ] Process has phase dependencies (`depends-on`) configured.
* [ ] Process input maps the source activity output to the destination activity input.
* [ ] Expression paths match the actual IDs (phase, activity, output names).

## Related topics

* [Passing activity outputs (complete walkthrough)](/release-orchestration/troubleshooting-and-resources/release-orchestration-use-cases/passing-activity-outputs.md)
* [Variable mapping](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-mapping.md)
* [Activity variables](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-types/activity-variables.md)
* [Phase dependencies](/release-orchestration/use-release-orchestration/release-orchestration-phases/phase-dependencies.md)

{% @harness-feedback/feedback %}