Building Workflows

In many cases, you can apply optimizations by taking one of the pre-made workflow templates, creating a workflow off of the template, and customizing it to your liking. When there’s no template to bootstrap from, you can create a new workflow from scratch. To end up with a minimally usable workflow, you need to:

1. Create a new workflow
2. Add a trigger
3. Add at least one action
4. Test the workflow
5. Publish the workflow

Every workflow is made of steps. There are two types of workflow steps: triggers and actions.

• A trigger is your workflow’s first step. It defines how often your workflow executes. It may also represent an event that needs to occur for your workflow to kick off. A workflow always has exactly one trigger.
• Actions are all subsequent steps of your workflow that start executing once your workflow is activated by a trigger.

Below is an example of a workflow that is triggered on a schedule. The first node represents the schedule trigger, and all other nodes are actions: In another example, here’s a workflow that uses an update of a Jira Cloud issue as a trigger:

​

Creating a new workflow

To create a new empty workflow, go to the Workflows section in your OpenOps instance, and click New Workflow in the top right corner. What you’ll see is the workflow editor, which initially looks like this: Let’s look around and see what controls the editor provides:

• In the top left corner, if you click the arrow next to the workflow name, Untitled, you get access to a menu that lets you rename the new workflow, delete it, or move it to a folder for better organization:
• The icon to the left of the workflow folder and name is a switch that lets you show or hide the sidebar, which contains the main OpenOps navigation menu.
• To the right of the workflow name, you have several buttons: Tree view, Version history, Run logs, and Notes. Version history and run logs will be more relevant when you update or troubleshoot your workflows later on. For now, you can use Notes to describe the intent of your workflow in detail or leave any other comments for future reference. You can also click Tree view to display an aside showing the compact structure of your workflow, including its trigger, all actions, as well as conditions and branches:

​

Adding a trigger

When you create a new workflow, the editor creates an empty stub trigger. Click the trigger node to select a trigger group that works for you: After selecting a group, choose a specific trigger within that group: OpenOps provides over 10 triggers divided into several groups:

• Schedule: Every X minutes, Every hour, Every day, Every week, Every month, Cron expression.
• Jira Cloud: New issue, Updated issue.
• Linear: New issue, Updated issue, Removed issue.
• IMAP: New email.
• Microsoft Outlook: New email.
• Webhook: Catch webhook.

Some triggers are used more often than others. For most of your scenarios, you will probably use one of the triggers in the Schedule group, setting your workflows to run at a predetermined interval. For details on schedule triggers, see Scheduling. After selecting a trigger, click the trigger node again to display a right-hand pane with the properties of the trigger. For example, here are the properties of the Every day trigger: You can choose a specific hour in a specific time zone and include weekends, or go with the reasonable defaults. Properties will vary with each type of trigger. For example, if the trigger is a new issue in Jira Cloud, you can specify a search query using Jira’s JQL query language.

​

Adding actions

As soon as you’ve created a trigger, the next and all subsequent steps of your workflow will be actions.

​

Adding the first action

Click the + icon under the trigger, and a pop-up menu will display a list of available action categories. Clicking a category lets you select a specific action: OpenOps provides a total of 120+ actions. One way to make sense of them is to classify them by intent:

• To get data for your workflow to process, look at cloud provider integration actions like AWS, Azure or Google Cloud, recommendation provider actions such as Umbrella, Archera and AWS Compute Optimizer, or generic HTTP actions.
• To control the execution of your workflow, use actions grouped under Condition and Split, Loop on items, Delay, and Stop Execution.
• To process data obtained in previous steps, use Date, List, Math, and Text operations, Data mapper for advanced transformations, and Code for transformations that you can’t express with available no-code actions.
• To request human intervention, use Approval or Slack.
• To make or request changes to cloud resources, use cloud provider actions, IaC integration actions like AWS CloudFormation and Terraform, and the GitHub action.
• To make updates in project management tools, use Jira Cloud, Linear, Zendesk, or Monday.com actions.
• To save data and generate reports, use SMTP, SFTP, Storage, and OpenOps Tables actions.

When you select an action, OpenOps adds it to the workflow graph and displays a right-hand pane with the properties of the action: The specific set of properties depends on the type of action. Here are a few general rules:

• Actions that get data from or send data to external resources will require you to define a connection. For example, for AWS-related actions, you’d need to specify your access key ID, secret access key, and the default region. For a Slack connection, you’d specify your Slack instance’s redirect URL, your client ID, and your client secret. One connection can be reused across multiple actions, and the OpenOps UI provides a separate view to list all connections you have defined so far.
• Actions that process data obtained in previous steps will ask you to specify the input data. For details, see Passing Data Between Workflow Steps.
• You can get AI assistance in many actions that involve writing CLI commands (AWS CLI, Azure CLI, Google Cloud CLI), SQL queries (AWS Athena, Snowflake, Databricks, BigQuery), or custom code. To enable AI assistance, you’ll need to connect OpenOps to an LLM provider of your choice. OpenAI, Anthropic, Perplexity, and a dozen other LLM providers are supported.
• Every action has two toggles: Continue on Failure, which lets the current action fail and continues the workflow regardless, and Retry on Failure, which retries the current action up to four times before giving up.

​

Adding more actions

You can add more actions by clicking the + icon in the workflow graph. You don’t need to add actions sequentially: the + button is available between existing actions, allowing you to add new actions in the middle of your workflow.

​

Copying and pasting steps

If you need to reuse an action step in multiple places, you can copy/paste it. This copies the action along with all its property values, saving you the trouble of reconfiguring it. For example, you can copy/paste actions between different workflows, or between conditional branches of the same workflow that often end up sharing a part of their containing actions. There are three ways to use copy/paste actions:

1. With the standard copy/paste keyboard shortcuts (Ctrl+C/V or Cmd+C/V on Mac). When you paste this way, the copied action is inserted after the action that is currently selected in the workflow graph.
2. Using the right-click context menu of any action:
3. By clicking the overflow menu of any action:

There are several ways to paste the copied action:

• Select an action after which you want to insert the copied action, then right-click and choose Paste after.
• Right-click the + icon between two existing actions and click Paste here:
• Right-click a loop action and select Paste inside loop. This inserts the copied action as the first action inside the loop:
• To paste as the first action after a loop or condition, right-click anywhere inside the loop or condition and click Paste after selection.
• To paste as the last action in the workflow, right-click anywhere outside the workflow graph and click Paste after selection.

​

Collapsing and expanding steps

As you add more actions to your workflow, you’ll notice that the workflow graph becomes more cluttered and harder to navigate. This is even more evident when your workflow includes many loops and conditions. To make it easier to navigate complex workflows, you can collapse steps representing loops, conditions, and split actions. For example, in the following image, step 7 is a condition with a branch that contains another condition: If you’re not currently working on this part of the workflow, you can collapse it by clicking the collapse icon to the left of step 7: Click the icon again to expand the condition the next time you need to work on it.

​

Testing a workflow

As you build your workflow, you should test individual steps (both the trigger and all actions) in isolation. Once you’re done editing and testing the steps, you should also test the entire workflow to make sure that everything works as expected.

​

Testing individual steps

In the properties pane for every step, there are two tabs: Configure and Test. When you click the Test tab, it displays two sections: Step output and Sample output data. Under Step output, you can click Test Step to test or retest the step in isolation. “Testing” in this context means running the step’s action against a live system that it is configured to connect to. Sometimes, the Test Step button may be grayed out, like this: Your step will also have a yellow warning icon next to it. If this happens, make sure you have filled in every mandatory input field in the step’s properties pane. You may need to scroll through the properties pane to see all required fields: Once you’ve filled in all mandatory fields, the Test Step button becomes active. Click it to run the test and view the output generated by the step: If you don’t have a connection defined when working on a step, or if you want to avoid running the step against a live system for any other reason, open the Sample output data tab. Once there, paste the expected output of the step. Depending on what the step’s action does, this could be the result of a math operation, a JSON response from an API call, or similar. Finally, click Apply: This lets you avoid running the step against a live system while still being able to provide input data for subsequent steps in your workflow. All steps that use sample output data have a corresponding label in the workflow graph:

​

Testing the entire workflow

As soon as you have implemented and tested all steps, including a trigger and actions, it’s time to test your entire workflow. If all the steps in your workflow are complete, you’ll see the Test Workflow button at the top of the workflow editor, right above the trigger node: If some of the steps aren’t complete, you’ll see the Complete n steps button at the top of the workflow editor instead. Incomplete steps will also be marked with a yellow warning icon: Click Complete n steps to navigate to the first incomplete step in your workflow. Locate the remaining incomplete steps by the yellow warning icons next to them. As soon as you’ve made sure that all individual steps are complete, go back to the top of the workflow editor and press Test Workflow. Note that when you test the entire workflow, OpenOps will ignore any sample output data you may have provided for individual actions. Instead, it will run all actions in the workflow against their respective live systems. After performing a test run of the workflow, OpenOps will show the results of the run in the Run Details pane to the left of the editor, indicating the status of each step, as well as its inputs and outputs:

​

Publishing a workflow

When you’re happy with your workflow and want to start running it, click Publish in the top right corner. This also applies when you’re editing an existing workflow: to avoid disrupting pending workflow runs, your changes won’t take effect until you publish them.