> 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-processes/overview.md).

# Overview

Learn about release processes and how they model release workflows.

Processes are the foundation of release orchestration. A **process** is a reusable blueprint that defines the structure of a release. A **process** is the foundational element in release orchestration and serves as a reusable, end-to-end model for how software is delivered within an organization. It captures all required activities across multiple teams, tools, and environments by structuring them into clearly defined, executable steps. As a reusable blueprint, a process lets you manage release types from a **Standard Release Process** to an **Emergency Hotfix**. It supports consistent, repeated execution across the organization. Typically, a process is organized hierarchically, comprising multiple **phases**. Each phase contains one or more **activities**, which may be automated (such as running pipelines), manual (such as approvals or sign-offs), or other subprocesses for complex workflows. By modeling releases as processes, organizations can achieve standardization, ensuring every necessary step, such as testing, security checks, compliance reviews, and production deployments, is explicitly tracked, enforced, and repeatable for every release.

### What you will learn from this topic

* How a process models [the essential components](#essential-components-of-process) of a release workflow
* How processes deliver [standardization, governance, and reusability](#key-benefits) across releases

### Essential components of a process <a href="#essential-components-of-process" id="essential-components-of-process"></a>

In the overview, we discussed the Harness entities associated with the process. The following section provides a visual overview of these components:

* **Phases**: logical groupings of activities (for example, planning, build, testing/validation, feature flags, deployment, monitoring).

<figure><img src="https://478177610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwRDYqBolZUj6Rwnqx0mm%2Fuploads%2Fgit-blob-070ef7756ceabe0922f6408bc4f12d4940c8ded2%2Fphases.png?alt=media" alt=""><figcaption><p>Click to view full size image</p></figcaption></figure>

* **Activities**: work units within phases (automated/pipeline, manual, or subprocess).

<figure><img src="https://478177610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwRDYqBolZUj6Rwnqx0mm%2Fuploads%2Fgit-blob-d8f6d0f1fe162ea46c4c19c7c552b8e6c00e5776%2Factivities.png?alt=media" alt=""><figcaption><p>Click to view full size image</p></figcaption></figure>

* **Dependencies**: execution ordering between phases and activities.

<figure><img src="https://478177610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwRDYqBolZUj6Rwnqx0mm%2Fuploads%2Fgit-blob-6ce7e3ba6b31b100717f14ca8b2087037a4ab1fb%2Fdependencies.png?alt=media" alt=""><figcaption><p>Click to view full size image</p></figcaption></figure>

* **Owners**: who is responsible for phases/activities (for collaboration and sign-off).

<figure><img src="https://478177610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwRDYqBolZUj6Rwnqx0mm%2Fuploads%2Fgit-blob-784f5cb13dd6af40c335f352b784eb0b8d51203a%2Fowners.png?alt=media" alt=""><figcaption><p>Click to view full size image</p></figcaption></figure>

* **Variables**: the set of inputs required to run a release, using variable mapping.

<figure><img src="https://478177610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwRDYqBolZUj6Rwnqx0mm%2Fuploads%2Fgit-blob-fa87f33d28ee9c63ab37604e44860b75714a0f36%2Finputstore-variables.png?alt=media" alt=""><figcaption><p>Click to view full size image</p></figcaption></figure>

### Key benefits <a href="#key-benefits" id="key-benefits"></a>

Processes enable you to standardize release workflows, make ownership explicit, and run releases with clear visibility and auditability. They provide:

* **Clarity and visibility**: Processes make release workflows explicit and auditable. Each step is modeled as an activity, with clear ownership and responsibilities.
* **Governance**: Auditable processes help meet regulatory requirements and enable granular tracking of approvals, changes, and incidents.
* **Automation**: Automated activities can execute pipelines or scripts, reducing manual effort and error.
* **Reusability**: Common patterns (like pre-deployment validations or rollback procedures) can be encapsulated as reusable process templates.
* **Flexibility**: You can tailor processes to support diverse release types (standard, emergency, feature rollout, and so on), linking them to different tools, environments, and input requirements.

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

* [Process modeling](/release-orchestration/use-release-orchestration/release-orchestration-processes/process-modeling.md)
* [AI-based process creation](/release-orchestration/use-release-orchestration/release-orchestration-processes/ai-based-process-creation.md)
* [Phases](/release-orchestration/use-release-orchestration/release-orchestration-phases/phases-overview.md)
* [Activities](/release-orchestration/use-release-orchestration/release-orchestration-activities/activities-overview.md)
* [Move a process to Git](https://developer.harness.io/harness-platform/use-harness-platform/git-experience/move-inline-entities-to-git#move-inline-process)

{% @harness-feedback/feedback %}