> 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/subprocess-activities.md).
# Subprocess Activities
Learn about subprocess activities and how to compose release processes from other processes
Subprocess activities allow you to include other processes as activities within a process, enabling process composition and reusability. This feature lets you build complex release workflows by combining simpler, reusable process components.
### What you will learn from this topic
* Understand [what a subprocess activity is](#what-are-subprocess-activities) and [when to use one](#when-do-you-need-sub-processes)
* How to [configure](#configuration) a subprocess activity, including input, variable, and output mapping
* How a subprocess [executes](#subprocess-execution) and how status propagates to the parent process
* How to apply the [best practices](#best-practices) for designing and nesting subprocesses
### What are subprocess activities?
Within Release Orchestration's process model, subprocesses are a natural extension: smaller, reusable processes invoked from a parent process. A Process is defined as a release (process) YAML that contains phases, each of which contains activities. A subprocess is another process definition that can be invoked by a parent process as a specialized activity or phase, with its own phases, activities, and inputs.
Subprocess activities enable process composition, allowing you to build complex processes from simpler ones. They enable reuse by allowing you to apply common process patterns across multiple releases.
They support modularity by helping you break down large processes into manageable components, and they enable the use of templates so you can create standardized process templates that can be invoked with different configurations.
### When do you need subprocesses?
Subprocesses make sense in several scenarios where you need more flexibility or organization than a single flat process can provide.
**1. You have repeatable flows reused across multiple releases**
When you have standard workflows that appear in multiple releases, subprocesses help you avoid duplication. For example, a standard "Security & Compliance" flow that includes running security scans, collecting approvals, and generating evidence can be modeled once as a process, then called from multiple main release processes.
This ensures consistency while reducing maintenance overhead.
**2. You need modularity for large releases**
Very large releases may span multiple domains, such as frontend, backend, data, and infrastructure, or they may exceed the comfort limits of a single process file.
In these cases, you can model each domain as a subprocess and orchestrate them from a parent process, making the overall release structure more manageable and easier to understand.
**3. You want independent evolution of parts of the release**
When different teams own specific segments of a release, such as infrastructure or security, subprocesses allow those teams to evolve their processes independently.
The parent process references a stable interface defined by inputs and outputs rather than duplicating logic, so teams can improve their subprocesses without affecting the parent process structure.
**4. You need different cadences or reuse patterns**
A subprocess might be run as part of a release, or executed manually or on a different cadence for validation, dry runs, or recurring operations.
This flexibility lets you reuse the same process definition in multiple contexts, whether it is part of a larger release or a standalone operation.
### Architectural note
Subprocesses are just other process YAMLs executed via the same orchestration engine, wired into the parent via activity/template glue, and shared InputStore.
### Configuration
The following interactive walkthrough shows how to configure a subprocess activity and pass custom input variables to it. The YAML examples after it show the same configuration in code.
{% @arcade/embed url="" flowId="0nVXZZeUtfdSidkdDW6w" %}
**Basic configuration**
```yaml
activity:
name: "Deploy Service"
type: "subprocess"
process: "Standard Service Deployment"
```
**Input mapping**
Map inputs to subprocess:
```yaml
activity:
name: "Deploy Service A"
type: "subprocess"
process: "Service Deployment Template"
inputs:
service_name: "Service A"
environment: "${target_environment}"
version: "${service_a_version}"
```
**Variable mapping**
Map variables to subprocess:
```yaml
activity:
name: "Deploy Service"
type: "subprocess"
process: "Service Deployment"
variables:
deployment_timeout: "${global.deployment_timeout}"
rollback_enabled: true
```
**Output mapping**
Capture subprocess outputs:
```yaml
activity:
name: "Deploy Service"
type: "subprocess"
process: "Service Deployment"
outputs:
deployment_id: "${subprocess.deployment_id}"
deployment_status: "${subprocess.deployment_status}"
```
### Subprocess execution
**Execution context**
A subprocess executes in its own context with variable scope isolation, meaning variables defined in the subprocess do not interfere with the parent process unless explicitly mapped. The subprocess has an independent execution status, separate from the parent, and manages its own dependencies.
It also maintains separate logs, making it easier to troubleshoot issues within the subprocess without sifting through parent process logs.
**Status propagation**
The subprocess status affects the parent process in different ways depending on the outcome. When the subprocess completes successfully, the parent can proceed. If the subprocess fails, the parent handles the failure according to its error handling configuration.
If the subprocess is skipped, the parent continues execution. While the subprocess is executing, it shows an "In Progress" status that the parent process tracks.
**Error handling**
Handle subprocess errors:
```yaml
activity:
name: "Deploy Service"
type: "subprocess"
process: "Service Deployment"
on_failure: "stop" # or "continue", "retry"
```
### Nested process structure
**Process hierarchy**
Processes can be nested at multiple levels:
```
Main Process
└─ Phase 1
└─ Subprocess Activity
└─ Nested Process
└─ Phase A
└─ Activity
```
**Variable scope**
Variable scoping in nested processes follows a hierarchy: global variables are available at all levels; process variables are available within the process; phase variables are available within the phase; and activity variables are available within the activity.
This scoping ensures that variables do not leak between processes unintentionally while still allowing you to pass values where needed.
### Best practices
**Process design**
Design processes for reuse by making them self-contained with minimal external dependencies. Processes should be configurable, accepting inputs and variables that allow them to be used in different contexts.
They should also be well-documented, with clear information on purpose and usage, so other teams can use them effectively.
**Error handling**
Handle subprocess errors appropriately based on the failure's severity and impact. Stop on critical errors to fail fast and prevent cascading problems, but continue on non-critical failures when the release can proceed safely.
Implement retry logic where appropriate for transient failures, and ensure error reporting provides clear error messages that help diagnose and fix issues quickly.
**Performance**
Consider performance implications when using subprocesses. Be aware of subprocess execution time and how it affects overall release duration.
Enable parallel execution of subprocesses when they do not depend on each other, which can significantly reduce total execution time. Monitor resource consumption to ensure subprocesses do not overwhelm your infrastructure, and cache results where possible to avoid redundant work.
### Related topics
* [Activities Overview](/release-orchestration/use-release-orchestration/release-orchestration-activities/activities-overview.md)
* [Process Modeling](/release-orchestration/use-release-orchestration/release-orchestration-processes/process-modeling.md)
* [Modeling complex processes](/release-orchestration/use-release-orchestration/release-orchestration-processes/process-modeling.md#modeling-complex-release-processes)
{% @harness-feedback/feedback %}