Process Modeling
Learn how to model release processes using phases, activities, and dependencies.
Process modeling in Release Orchestration allows you to define your release workflows using phases, activities, dependencies, and variables. You can create processes using AI-based generation or manual configuration to match your team's specific requirements.
Create a process with AI
Harness supports creation of processes using Harness AI. Most of the time, release processes are available in a textual fashion, documented in different sources. Release Orchestration enables users to provide that process documentation and create the process as an entity in Harness Release Orchestration.
To create a process with Harness AI, navigate to Processes, then click Create Process.

Enter instructions that define your release process. Use the following example:
Example prompt:
After you submit the prompt, Harness AI performs the following actions:
Creates phases: Identifies logical groups of activities as phases.
Assigns owners: Assigns owners from the prompt or asks you to provide them.
Creates activities: Generates activities within each phase.
Infers dependencies: Determines execution order and dependencies.

Harness AI asks you to provide owners for each phase. After you select owners, Harness AI creates YAML for the release process. The YAML appears as a step-by-step release process.

You can define phases, activities, and dependencies manually to match your release process. Use Harness AI when you want to generate a starting process.
Process structure
Basic structure
A process has the following elements:
Metadata: Name and description
Inputs: Required parameters (captured using an Input Store when executing)
Variables: Process-wide variables
Phases: Major stages
Activities: Tasks within phases
Dependencies: Execution order rules
YAML example
The following example uses the same YAML shape as a real process created in Release Orchestration (nested phase and activity blocks, depends-on, owners, and optional if and data fields).
Model complex release processes
You can model complex release processes with different sequences of execution in terms of parallel and sequential execution.
Common execution patterns
Sequential Execution
Activities execute one after another:
Parallel Execution
Activities execute simultaneously:
Conditional Execution
Activities execute based on conditions:
Phase Dependencies
Phases can have dependencies preconfigured. For example:
The test phase has dependencies on the build phase
The validation phase has dependencies on the build phase
Phases execute in the order defined by their dependencies
Activity Dependencies
Activities within each phase can also have dependencies. For example:
Activity 3 (a manual pipeline or automated activity) and Activity 3.1 (a manual activity) are dependent on Activity 2 (an automated pipeline activity)
Activities execute in the order defined by their dependencies
Dependencies can be configured to support both parallel and sequential execution
Complex process structure example
A pre-built, preconfigured process might have:
Build Phase: Contains build activities
Test Phase: Depends on Build Phase, contains test activities
Validation Phase: Depends on Build Phase, contains validation activities
Activities with dependencies: Activities within phases that depend on other activities
With this structure, it is possible to model complex release processes and execute them using a release.
Git-backed processes
For git-backed processes, Harness resolves activities based on the following rules:
Activity resolution rules
branchA
Inline activity
✅ Resolves
branchA
branchA (same repo)
✅ Resolves
branchA (repoA)
Default branch (repoB)
✅ Resolves
branchA (repoA)
branchB (repoA)
❌ Shows as Unknown
Key behavior: Harness fetches activities from the same branch where the process is stored.
Resolution failure
Activities show as Unknown when the process and activity are in the same repository but different branches. The activity becomes non-editable in the UI.
Example:
Process in
release-v2branchActivity in
mainbranch (same repository)Result: Activity shows as Unknown
Configuration options
Use one of the following approaches:
Store activities in the same branch as the process
Store activities in a different repository (reference from default branch)
Define activities inline in the process YAML
Process blueprints
Start with blueprints for common scenarios:
Standard production release
Hotfix release
Multi-service release
Scheduled release
Customize a blueprint to fit your needs.
Related topics
Last updated
Was this helpful?