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.
• SFTP: New file.
• Webhook: Catch webhook.
• Slack: New message, New reaction.
• Jira Cloud: New issue, Updated issue.
• Monday.com: New item in board, Specific column value updated in board.

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 an action

As soon as you’ve created a trigger, the next and all subsequent steps of your workflow will be actions. 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 Anodot 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 End Workflow.
• 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 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.
• 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.

​

Testing a workflow

Underneath the properties pane, every action has a Generate Sample Data section and a Test Step button, which lets you test or retest the action in isolation. Sometimes, this 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 action’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 action:

As soon as you have implemented all steps, including a trigger and actions, it’s time to test your entire workflow. If all the steps of your workflow are complete, you can 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. After performing a test run of the workflow, OpenOps will show 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.