Workflows

A workflow is a defined process for a kind of work, such as taking a ticket to a reviewed pull request, or patching a vulnerability across services. Each workflow is made of steps, and each time it runs, OpsLevel records every step's status and output.

Create a workflow

1. Go to Workflows and select New workflow.
2. Add steps to the canvas with the + button, and connect them in the order they should run.
3. Select a step to edit its settings in the side panel.
4. Add kickoff inputs for any information a run needs when it starts.
5. Optionally, add a trigger to start runs automatically.
6. Select Save workflow.

The editor shows Ready to save once every step is configured.

Steps

Use a Wait step to give something time to happen before the next step, for example waiting 30 minutes for CI to finish, or a day before following up on a ticket.

Step IDs and outputs

Every step has a step ID. Later steps can use a step's output with steps.<step id>.output. For example, if an Automation step's ID is check_ticket, a later step can read its result at steps.check_ticket.output.

Step settings use Liquid templates to insert values:

Generate a fix for this issue:
{{ steps.check_ticket.output.summary }}

Turn on View as Liquid in the editor to see the template behind each step.

Branches

A step can branch the workflow based on its output. For example, an Automation step that checks whether a ticket is ready can send the run down a True branch to generate a change, or a False branch to comment on the ticket asking for more information. Name branches after what they mean, such as Update available and No updates.

Kickoff inputs

Kickoff inputs are the information a run starts with, such as a ticket ID or description. Any step can use them.

• When you start a run manually, OpsLevel asks for each input.
• When a trigger starts a run, the trigger fills in the inputs from its data.

Triggers

You can always start a workflow manually. To start runs automatically, add one trigger. A workflow can have at most one trigger.

Webhook triggers

• Webhook URL: send deliveries here. Treat it like a secret.
• Condition (jq): optional. A delivery starts a run unless this produces false or null. Use it to start runs only for certain events, such as tickets with a specific label.
• Kickoff inputs (jq): for each kickoff input, a jq expression that pulls its value from the delivery. Leave one blank, or produce null, to leave it unset.

For example, this condition starts runs only for Linear issues labeled OpsLevel Workflow:

([.data.labels[]? | select(.name == "OpsLevel Workflow") | .id][0]) as $id
| .type == "Issue" and $id != null

And these inputs pass the issue's ID and description to the run:

Schedule triggers

Enter a cron expression in UTC. For example, 0 0 1 * * runs at midnight UTC on the first day of each month. The workflow page shows the next scheduled run.

Runs

Each run appears on the workflow's Runs tab, with its status, start time, who or what started it, and duration. Select a run to see each step's status, output, and logs. See Workflow runs for approvals, failures, and cancelling runs.