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.
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).
These are key pieces of information about the run.
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.
The timeline shows all triggers, tasks, and errors that are part of this run. They will be listed in order of occurrance (by time). This is a summary view showing everything but inputs and outputs and is the default view. It can be most helpful in troubleshooting.
Each item on the timeline can be clicked on to open it to show more details about it. You can only have one item on the timeline open at a time.
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:
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:
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.
A deferred task is one that does not complete right away, but pauses the workflo 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.
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 generally add a lot of triggers and tasks to a timeline. The important keys are this:
are part of the first instance of the loop and all with
are part of the second instance of the loop, etc. This is how you can tell which task goes with which.
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.
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.
This menu shows the triggers that you see in the timeline. The details are the same, it can just be easier to read without the mixed types.
This menu shows the tasks that you see in the timeline. The details are the same, it can just be easier to read without the mixed types.
This menu shows the errors that you see in the timeline. The details are the same, it can just be easier to read without the mixed types.
This tab is only present for routines and captures what outputs were sent out of the routine.