Workflows define the deployment orchestration steps, including how a Service is deployed, verified, rolled back, and more.

Some of the common Workflow types are Canary, Blue/Green, and Rolling. An Application might have different deployment orchestration steps for different Environments, each managed in a Workflow.

In this topic:

For information about how Workflows are used in deployment environments, see Deployment Guides.

Intended Audience

  • DevOps

Before You Begin

Video Summary

Add a Workflow

The following steps cover the common Workflow setup.

To add a Workflow, do the following:

  1. Click Setup.
  2. Click the application where you want to put the Workflow.
  3. Click Workflows.
  4. Click Add Workflow. The Workflow dialog appears.
  5. Give your Workflow a name and description that tells users its purpose. For example, if the Workflow takes a service with a Docker artifact and deploys it to a Kubernetes environment in GCP, you might name the workflow docker-to-k8s-GCP.
  6. In Workflow Type, select the type of Workflow you want to perform. For a summary of the types, see Workflow Types below.
  7. In Environment, select the environment where you want to deploy the service. Select from the environments you added in Add an Environment.
  8. In Service, select the service you want to deploy.
  9. In Service infrastructure, select the Service Infrastructure where you want the Workflow to deploy the Service.
    1. If you are using Infrastructure Definitions (which is a feature-flagged replacement for Service Infrastructure), in Infrastructure Definition, select the Infrastructure Definition where you want the Workflow to deploy the Service.
  10. Click SUBMIT. The Workflow is created. Here is an example of a Basic Deployment.

If this is a Basic Deployment, you might need to update one step before using the Workflow. For example, in the figure above, the Upgrade Containers step requires attention. In the case of other deployment types, there might be additional steps to configure.

Workflow Types

The following table lists the Workflow types available when creating a Workflow.

Workflow Type



A Basic deployment selects nodes and installs a service.


A Multi-Service uses one or more phases composed of separate steps.


A Canary deployment rolls out a new app version to small sets of users in separate phases, tests and verifies it at each phase, gradually rolling it out to your entire infrastructure.


A Build deployment simply collects artifacts.


A Rolling deployment lets you gradually roll out your deployment, enabling and disabling services as necessary.


In a Blue/Green deployment, network traffic to your service/artifact is routed between two identical environments called blue (staging) and green (production). Both environments run simultaneously, containing different versions or the service/artifact.

When you submit, the Workflow will display the steps needed to perform the Workflow type you selected.

Workflow Steps and Commands

Different Workflow deployment types involve different Workflow steps. Each type of step, such as Deploy Containers or Verify Service, has specific commands available to it.

To add commands to steps, do the following:

  1. Under the Workflow step, click Add Command.
    For setup or pre-deployment steps, such as Setup Container, you will see Cloud, Flow controls, and other general commands:
  2. To use a template, click Add Command, and then click From Template Library. For more information, see Use Templates.
  3. If a step has multiple commands, you can arrange them. Mouseover the command and then click the down arrow.
  4. You can control how multiple commands under a step are executed. Click the vertical ellipsis next to a step with multiple commands. The execution drop-down appears.


When deploying interdependent services, such as micro-services or a large and complicated application, there might be a need to coordinate the timing of the different components' deployments. A common example is the need to verify a group of services only after all the services are deployed successfully.

Harness Workflows address this scenario using barriers. Barriers allow you to synchronize different Workflows in your pipeline, and control the flow of your deployment systematically.

Barriers have an effect only when two or more Workflows use the same barrier name, and are executed in parallel in a Pipeline. When executed in parallel, both Workflows will both cross the barrier at the same time.

If a Workflow fails before reaching its barrier point, the Workflow signals the other Workflows that have the same barrier, and the other Workflows will react as if they failed as well. At that point, each Workflow will act according to its Failure Strategy.

To use a barrier, do the following:

  1. In your Workflow, click Add Command.
  2. Under Flow Control, click Barrier. The Barrier dialog appears.
  3. In Identifier, enter a name for the barrier. This name must be identical to all the other related barriers in the other Workflows you want to impact.
  4. In Timeout, enter the timeout period, in milliseconds. For example, 600000 milliseconds is 10 minutes. The timeout period determines how long each Workflow with a barrier must wait for the other Workflows to reach their barrier point. When the timeouts expire, it is considered a deployment failure.
You can have multiple barriers in a Workflow. Ensure the identifier string for each related barrier across the different Workflows matches.

Workflow Phases

In multi-phase deployments, such as a Canary Deployment, Workflow steps are grouped into phases. Here is a Canary Workflow before the phases and sub-steps are added:

To add a phase to a multi-phase deployment, do the following:

  1. In Deployment Phases, click Add Phase. The Workflow Phase dialog appears.
  2. In Service, select the Service to use for this phase.
  3. In Service Infrastructure, select the Service Infrastructure to use for this phase.
    1. If you are using Infrastructure Definitions (which is a feature-flagged replacement for Service Infrastructure), in Infrastructure Definition, select the Infrastructure Definition where you want the Workflow Phase to deploy the Service.
  4. If you want to override a variable that is defined in the Service you selected, in Service Variable Overrides, click Add. Enter the name of the variable to override, and the override value.
  5. Click Submit. The new phase Workflow appears. Complete the phase Workflow as you would any other Workflow. You can also define the Rollback Steps for this phase.
  6. When you are done, click the name of the Workflow in the breadcrumbs, to return to the Workflow overview and see the phase added to Deployment Phases.

Verify Steps

One of the most important steps in a Workflow is verification. A verification step ties your Workflow and your Verification Provider to Harness Continuous Verification features.

In order to obtain the names of the host(s) or container(s) where your Service is deployed, the Verify Steps should be defined in your Workflow after you have run at least one successful deployment.

To set up a verification step, do the following:

  1. In a Workflow, in Verify Service, click Add Verification. The Add Command dialog appears.
  2. In Verifications, click the Verification Provider connected to the Service you are deploying in this Workflow. The configuration dialog for the Service appears.
  3. Fill out the Verification Provider's configuration dialog and click Submit. The Verify Service step displays the Verification Provider.
In a multi-phase deployment, the verification steps are in the sub-steps within each phase.

You can read more about the different verification integrations in Continuous Verification and Verification Providers.

Rollback Steps

You define the steps of a Workflow rollback in Rollback Steps. Typically you want to rollback failed containers and container orchestration setup. You can also verify that the rollback has restored the last working version of your Service.

For Docker, Kubernetes, AWS CodeDeploy, and Lambda deployments, Harness rolls back the deployment to the state that received the new code. In case of a JAR, WAR, RPM, TAR, ZIP and other deployments, Harness provides default rollback steps (Disable, Stop, Deploy, Enable, Wrap-up). You can add custom commands in cases where you need to customize the rollback procedure.

If you deploy a Workflow and choose the Abort option during the running deployment, the Rollback Steps for the Workflow are not executed. Abort stops the deployment execution without rollback or cleanup. To execute the Rollback Steps, click the Rollback button.

To set up rollback steps, do the following:

  1. In a Workflow, click Rollback Steps to see the default steps. Here is an example of the default rollback steps in a Workflow that deploys a Docker image to a Kubernetes cluster:

Notification Strategy

By default, when a Workflow fails, the Account Administrator is notified. You can specify a notification strategy for a Workflow (or for a Workflow phase in a Canary or Multi-Service Workflow) that sends notifications using different criteria.

To add a notification strategy, do the following:

  1. In a Workflow, click Notification Strategy. The default notification step appears.
  2. To edit the default strategy, click the pencil icon next to the strategy item.
  3. To add a new notification strategy, click Add Notification Strategy. The Notification Strategy dialog appears.




    Click the drop-down to select the condition that will execute the notification strategy (Failure, Success, Paused). Click all the conditions that apply.


    Select Workflow or Workflow Phase (for Canary or Multi-Service) as the scope for the condition(s) you selected.

    User Group

    Select the User Group to notify when the condition is met within the scope. For information on setting up the notification channels for a User Group, see User Notifications and Alert Settings.

    You can also enter ${ to see a list of variables that can be used. These can be variables specified at the Service, Environment, and Workflow level.

    For example, you could create a Service variable named OpsAdmin and use that variable in User Group. Next, you could overwrite that variable in Environment with a new value, and then use that Environment variable in User Group. Or, you could create a Workflow variable named StageOpsAdmin and use that in Notification Group.

    For the Workflow scope, you may select Environment (${environmentVariable.varName}) and Workflow (${workflow.variables.varName}) variables.

    For the Workflow Phase scope, you may select Service (${serviceVariable.varName}), Environment, and Workflow variables.

Failure Strategies

A Failure Strategy defines how your Workflow handles different failure conditions. For example, if you are deploying a Service to a cluster of 100 nodes, what percentage of connectivity errors would you allow before failing the deployment?

There are two ways to define a failure strategy:

  • The Failure Strategy settings for the entire Workflow.
  • Step-level failure strategy for a Workflow step section.

Workflow Failure Strategy

To define the failure strategy for the entire Workflow, do the following:

  1. In a Workflow, click Failure Strategy. The default failure strategy appears.

    The default failure strategy is to fail the Workflow if there is any application error, and to rollback the Workflow execution. You can modify the default strategy or additional strategies.
  2. Click Add Failure Strategy. The Failure Strategy dialog appears.

The dialog has the following fields:

  • Failure - Select the type of error:
    • Connectivity Error: Harness is unable to connect to the target host/cluster/etc, or a provider, such as a Git repo.
    • Authentication Error: Harness is unable to authenticate using the credentials you supplied in the Cloud Provider, Artifact Source, Source Repo Provider, and other connectors.
    • Verification Error: If you have set up verification steps in your Workflow and a deployment event is flagged as an error by the step, Harness will fail the deployment.
    • Application Error: Harness encountered an application error during deployment.
  • Scope - Select the scope of the strategy. If you select Workflow, the Action will be applied to the entire Workflow. If you select Workflow Phase, then the Action will be applied to the Workflow Phase only.
    For example, if you selected Workflow Phase and then selected the Action Rollback Phase Execution, and a failure occurred in the second Phase of the Workflow, then the second Phase of the Workflow would be rolled back but the first Phase of the Workflow would not be rolled back.
  • Action - Select the action for Harness to take in the event of a failure, such as a retry or a rollback:
    • Manual Intervention: You will be prompted to approve or reject the deployment on the Deployments page.
    • Rollback Workflow Execution: Harness will initiate rollback.
    • Rollback Phase Execution: Harness will initiate rollback of the Phase.
    • Ignore: Harness ignores the failure and continues with deployment. This setting can confuse some users because the deployment will likely fail.
    • Retry: Harness will retry the step where the failure occurred.
    • End Execution: Harness will end the Workflow without rolling back.
    • Abort Workflow: Harness will abort the Workflow without rolling back.

Step-level Custom Failure Strategy

To define the failure strategy for the step section of a Workflow, do the following:

  1. Next to the step section title, click the More Options ⋮ menu. The step-level settings appear.
  2. In Failure Strategy, click Custom. The Failure Strategy dialog appears.
  3. Click Add Failure Strategy.
  4. Fill out the strategy. The dialog has the following fields:
  • Failure - Select the type of error, such as Verification, Application, etc.
  • Action - Select the action for Harness to take in the event of a failure, such as a retry or a rollback.
  • Specific Steps - Select any specific Workflow steps that you want to target for the Failure Strategy. The criteria for the strategy will be applied to those steps only.`

There is no Scope setting, like the Scope setting in the Workflow-level Failure Strategy, because the scope of this strategy is the step section.

  1. Click Submit. The failure strategy is added to the step section.

Concurrency Strategy

You can edit a Workflow's Concurrency Strategy section to override Harness' default Workflow queuing behavior. For details, see Using Concurrency Strategy to Control Queuing.

Add Workflow Variables

You can set variables in the Workflow Variables section of your Workflow, and use them in the Workflow step commands and settings. For information on variables and expressions, see Variables and Expressions in Harness and Passing Variables into Workflows and Pipelines from Triggers.

To use Workflow variables, do the following:

  1. In a Workflow, click the pencil icon next to Workflow Variables. The Workflow Variables dialog appears.
    The Workflow Variables dialog has the following fields.



    Variable Name

    Enter a name for the variable. When the variable is referenced elsewhere in you Harness application, the variable name is used.


    Select the data type, such as Text, Number, or Email.

    Allowed Values

    Enter a comma-separated list of values that users can select. The list will appear as a drop-down menu when the Workflow is deployed.

    Default Value

    Enter a value for the variable. A value is not mandatory.


    Select this option to enforce that a value for the variable is provided before the Workflow is executed.


    Select this option if the value of the variable specified here must not be changed.


    Provide a description of the variable that lets others know its purpose and requirements.

  2. In a command, use your variable by typing a dollar sign ($) and the first letter of your variable. Harness will load matching variable names. The syntax for variable names is ${}. For example, if you created a variable named Url, the variable name is ${workflow.variables.Url}.
    When you deploy the Workflow, by itself or as part of a pipeline, the variables are displayed in the Workflow execution step. if the variables require values, you will enter the values when you add the Workflow to a Pipeline in the Stage dialog or in the New Deployment dialog when you deploy the Workflow.

Template a Workflow

You can turn a Workflow into a Workflow template ("templatize it") by using variables for important settings such as Environment, Service, and Service Infrastructure. When the Workflow is deployed, the user must provide values for the settings you have defined as variables.

When you turn a Workflow into a template, if the Workflow still retains references to the entities it was originally created with (such as a Service), any attempts to delete these entities will result in an error, because the template is still using them. You will need to remove the references from the template before you can delete them.

To turn a Workflow into a template, do the following:

  1. In a Workflow, click the More Options ⋮ menu next to the Deploy button, and click Edit. The Workflow dialog appears. The Workflow settings that may be turned into variables have a [T] button in their fields.
  2. For each setting you want to turn into a variable, click the [T] button in its field. The field values are replaced by variables.
    If you are using Infrastructure Definitions (which is a feature-flagged replacement for Service Infrastructure), click the [T] next to Infrastructure Definition.
    You can pass in variables from Triggers to set values for these Workflow variables. For more information, see Passing Variables into Workflows and Pipelines from Triggers.
  3. Click SUBMIT. The new variables are displayed under Workflow Variables.
  4. To see how the Workflow variables are used, click Deploy. The Start New Deployment dialog appears, displaying the variables you created in the Workflow Variables section.

If you are using Infrastructure Definitions (which is a feature-flagged replacement for Service Infrastructure), in Infrastructure Definition, the Start New Deployment dialog looks like this:

When this deployment is run, users can select from the options for each setting from the Value drop-down. Now the Workflow is a template that can be used by multiple services.

In the Workflows page, Workflow templates are identified with a template icon.

The template option for Workflow settings fields is available in the main Workflow dialog in some Workflow types, whereas in multi-phase deployment types, it will be available in the sub-step Workflow dialogs for each phase.

Templatized Workflows in Pipelines

Once you have templatized a Workflow, you can use it in multiple stages of a pipeline.

For example, you can templatize the Environment and Service Infrastructure of a Workflow, and then use the same Workflow for both the QA and Production stages of a pipeline. When you add the Workflow to each stage, you simply provide QA and Production-specific values for Environment and Service Infrastructure or Infrastructure Definition variables.

Workflow Variables in QA Stage of Pipeline

Workflow Variables in Production Stage of Pipeline

Deploy a Workflow

Typically, deployments are performed in Pipelines, which are collections of one or more Workflows. You can deploy individual Workflows within the Workflow Overflow.

To deploy a Workflow, do the following:

  1. In a Workflow, click the Deploy button.
  2. Provide values for any required variables. These are Workflow variables created in the Workflow Variables section of the Workflow.
  3. Complete the Start New Deployment dialog and click SUBMIT. The Workflow is run according to the Workflow steps.
  4. After a Workflow is deployed, its deployment information is available on the Workflows page.
  5. Click a Timestamp for a Workflow to view a deployment.
For information about using Triggers to deploy Workflows, see Triggers and Triggers and Queued Workflows.

Abort or Rollback a Running Deployment

If you deploy a Workflow and choose the Abort option during the running deployment, the Rollback Steps for the Workflow are not executed. Abort stops the deployment execution without rollback or clean up. To execute the Rollback Steps, click the Rollback button.

Abort Button

Rollback Button

Clone a Workflow

You can use a Workflow as a template for future Workflows by cloning the Workflow. When you clone a Workflow, you can select what application to clone the Workflow into. Cloning a Workflow can increase Workflow development rapidly, and ensure consistency in Workflows across applications.

To clone a Workflow, do the following:

  1. In the Workflows page, or in the page for an individual Workflow, click the More Options ⋮ menu.
  2. Click Clone. The Clone Workflow dialog appears.
  3. Give the Workflow a new name and description.
  4. In Target Application, select the Application where you want the Workflow cloned. If you do not select an Application, the Workflow is cloned into its current Application.
    The Environment, Service Infrastructure (or Infrastructure Definition), and nodes used by the Workflow are not cloned into the target Application. You will need to set these up in the target Application.
  5. In Service Mapping, select the service in the target Application to use with the cloned Workflow.
  6. Click Submit.
  7. Navigate to the target Application and click the Workflow. It will have the -clone suffix.
  8. Add the Environment, Service Infrastructure (or Infrastructure Definition), and nodes needed for the Workflow.

Configure as YAML

You can configure a Workflow using YAML. You can view the YAML using the main Code editor, as described in Configuration as Code, or you can jump directly to the YAML of a specific Workflow in the Workflows page.

To configure a Workflow as code, do the following:

  1. In the Workflows page, click the code icon </>. The code editor appears, displaying your Workflow YAML.
  2. Modify the YAML of the Workflow as needed, and then click Save. If you like, you can verify your change in the Harness Manager interface.

Troubleshooting Workflows

The most common error with Workflows occurs when an Environment's connection to a Workflow is changed in such a way as to render it inoperable for a deployment of that Workflow. The error is displayed in the Workflows and Continuous Deployment pages:

This error can occur in the following circumstances:

  • A user changes the Environment Service Infrastructure (or Infrastructure Definition). For example, the user might remove a Service Infrastructure/Infrastructure Definition, or change its Deployment Type or Cloud Provider, so that the Workflow can no longer use the Environment to deploy its Service.
  • A user changes the Environment in a Workflow. If you open the Workflow dialog and, in Environment, you select a different Environment, then a Service Infrastructure/Infrastructure Definition must also be selected in Service Infrastructure/Infrastructure Definition.
  • The user clones a Workflow to a different Application that uses Services that cannot deploy to the Service Infrastructure/Infrastructure Definition in that Environment.

As a result of these changes, the Workflow has no functional Service Infrastructure/Infrastructure Definition specified, and you must select a new Service Infrastructure/Infrastructure Definition for each impacted Workflow/Phase.

Next Steps

How did we do?