What is a Run?

A run is the instance of a workflow. It is a record of each input, trigger, node, result, and output for that instance of the workflow.

Finding a Run

Since a run is a particular instance of a workflow, there are several ways to find it. All of these start in the Space -> Global Workflow -> Runs console.

This tab shows a list of the runs, most recent first. If working with testing, it is possible, you can just look for the name of the workflow you want among those recent runs. However, over to the left of the run screen is a set of options to filter this listing:

You will notice that this defaults to unfiltered. You can update these filters so that they combine to give you a filter that will help you fine the run you are looking for. Note that Create trees and routines will not have a submission id.

Reading a Run

There is a lot of information on the run page. Everything from very basic information like the run number to very detailed information like the duration in milliseconds of an individual task. Part of using the run screen effectively is knowing what information it presents and how you might be able to use that information.

Run Details

In the upper right of the run screen are the run details. These will look slightly different for the different entities. Essentially what is listed here is the source of the run, the name of the workflow for the run with a link to the builder, any source id, and any parent id (with a link to the parent run).

Tree:

Global Routine:

Local Routine:

These are key pieces of information about the run.

Menus and Actions

Then, before the content, are the tabs indicating the content available and the buttons showing the actions available.

The triggers, tasks, and errors sections will each have a number indicator showing how many of those items there are for this run. Note that a tree will not have the output tab, as trees do not have output (only routines do).

The run screen does not auto-refresh, so there is a refresh button. The builder button opens the builder. You may want to right click and open in a new tab/window for the builder, otherwise it will use your current tab/window. The actions button has two options: Create Manual Trigger and Run Again. Run Again will pull up a screen to run the routine/tree with the same inputs as that existing run. This is immensely helpful during testing. It can allow you to test updates in the tree without having to recreate the submission on the front-end each time. Create Manual Trigger is intended to be used to "restart" branches of execution that did not fire because a connector incorrectly evaluated to false. A manually created trigger can NOT be used to re-run tasks that have already executed. This functionality can cause unintended consequences and should be used with caution.

Tasks

Tasks reflect the nodes in the workflow that are doing a piece of work. These will display in the run, minimally, a task id, an updated time, and a branch id. The most useful piece of information out of that is that (1) the task executed and (2) at exactly what time -- particularly in comparison to the other items in the run.

However, many tasks will also contain Results. There are two kinds of results. There are results that will be there as soon as the task runs, and there are deferred results, that will be there once a deferred task is complete. We will discuss that more when discussing deferred tasks. They will both appear in the Results section of the task in the run. Also, the results of a task are editable. This may be necessary if there are data issues that contributed to an error. Any edits to task results are audited.

Tasks generally have three statuses: New, Deferred, and Complete.

• New: The task has not yet completed execution.
• Deferred: The initial actions in the task have been executed and the task is awaiting a update or complete trigger.
• Complete: The task has completed its execution.

Deferred Tasks

A deferred task is one that does not complete right away, but pauses the workflow while it waits for a trigger to return to it saying the task is complete. As such, if there is an open deferred task, it is often the last node displaying in a run. The workflow is waiting for it to complete before moving on.

In the run a deferred task will have three extra links:

These links allow you to go to the run for that deferred task or create a trigger for that deferred task. The links to create triggers for the task are there in case there is an issue with the deferred task and it cannot or will not be updated or completed "properly" but the workflow should move on.

Loops

Loops generally add a lot of triggers and tasks to a timeline. The important keys are this:

• If you only see a head and tail, the head evaluated so that there were no instances of the loop to execute.
• If there were instances of the loop to execute, each will have it's own head and that will have a number associated with it. There will be each node from inside that loop once for each instance of the loop with a number attached to it. So, all of the nodes with [0] are part of the first instance of the loop and all with [1] are part of the second instance of the loop, etc. This is how you can tell which task goes with which.

Inputs

The inputs tab displays the input provided for this run. For trees, this is source data; for routines, this is individual inputs. Either way, as with results, this is editable. Any edits to this are audited as well.

Triggers

Triggers are what tell the engine to do something. Start a workflow, pick back up a deferred task, retry an error, etc. There are three types of triggers:

• Root (Start)
• Update
• Complete

You will see this type indicated as the Action if you open a trigger on the timeline.

You will also the the originating run ID (which run sent/created the trigger). This is helpful to figure out where a routine was triggered from or where a task is being completed from.

Also you will see the originating task engine. You may not think this is useful, but it can be. There are often multiple engines in production environments. During upgrades, sometimes old engines are left around as backups and they accidentally get started up at a later date, causing odd behavior that has to be tracked down. Or perhaps only one server is causing a particular issue out of the 3 in production. This engine identification can help track issues like that.

Triggers generally have three statuses: New, Complete, and Failed:

• New: the trigger is in the system but not yet picked up by the engine.
• Complete: the trigger has been successfully executed by the engine.
• Failed: the trigger encountered an error when trying to execute.

Errors

Errors inside the run will be accompanied by a New Task and a Failed Trigger.

The error provides the error number with a link to the full error information, the type of error, and a summary of the error. Generally, you will need to follow the link and go to the full error page to troubleshoot and resolve the error.

Outputs

This tab is only present for routines and captures what outputs were sent out of the routine.