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.

Click to view full size image

Enter instructions that define your release process. Use the following example:

Example prompt:

Create a multi-service release process starting from release planning and coordination up until monitoring in production. The process includes the following phases:
- Release planning and coordination (Owner: Release Manager)
- Build and artifact creation
- Testing and validation
- Feature flag enablement
- Production deployment
- Monitoring and rollback

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.

Click to view full size image

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.

Click to view full size image

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:

1. Metadata: Name and description

2. Inputs: Required parameters (captured using an Input Store when executing)

3. Variables: Process-wide variables

4. Phases: Major stages

5. Activities: Tasks within phases

6. 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).

process:
  name: Comprehensive Release Process
  description: A structured release process covering build, test, and deployment phases
  id: comprehensive_release_process
  phases:
    - phase:
        id: build_phase
        name: Build Phase
        description: Build and validate artifacts before testing.
        owners:
          - Development Team
        depends-on: []
        activities:
          - activity: AutoPipe
            id: AutoPipe
            name: AutoPipe90
            description: ""
            depends-on: []
          - activity: AutoPipe
            id: AutoPipe12
            name: AutoPipe12
            description: ""
            depends-on:
              - AutoPipe
          - activity: AutoPipe
            id: TestActivity00
            name: TestActivity00
            description: ""
            depends-on:
              - AutoPipe12
            if: <+90>
          - activity: ManualTest
            id: AutoIioo
            name: Auto_deploy
            description: doc
            depends-on:
              - AutoPipe12
    - phase:
        id: test_phase
        name: Test Phase
        description: Execute tests and quality gates before deployment.
        owners:
          - QA Team
        depends-on:
          - build_phase
        activities:
          - activity: TestActivity
            id: TestActivity
            name: TestActivity
            depends-on: []
    - phase:
        id: deploy_phase
        name: Deploy to Staging1 Phase
        owners:
          - DevOps Team
        depends-on:
          - test_phase
        activities:
          - activity: WaitingActivity
            id: WaitingActivity
            name: WaitingActivity
            depends-on: []
            data:
              pipeline:
                pipeline: default/MyProject/MyPipeline
                inputSet: {}

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:

Activity A → Activity B → Activity C

Parallel Execution

Activities execute simultaneously:

Activity A ─┐
            ├→ Activity D
Activity B ─┤
            └→ Activity E
Activity C ─┘

Conditional Execution

Activities execute based on conditions:

Activity A → [Condition] → Activity B (if true)
                      └→ Activity C (if false)

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

Process Location	Activity Location	Resolution Status
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-v2 branch

• Activity in main branch (same repository)

• Result: Activity shows as Unknown

Configuration options

Use one of the following approaches:

1. Store activities in the same branch as the process

2. Store activities in a different repository (reference from default branch)

3. Define activities inline in the process YAML

Store processes and their activities in the same branch to ensure correct resolution.

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

• Phases

• Activities

• Activity Dependencies

• Modeling complex processes