General concepts

Workflow Templates and Workflow Runs

Workflows in Laboperator provide a powerful tool to orchestrate devices and data with information and control elements which enable lab scientists to create a digital twin of their processes in the laboratory. Workflows operate as a connecting layer between the device integration layer harmonizing device interfaces, commands and data and the API layer which provides data, commands and resources in a unified format to third parties. Workflows can be utilized to provide the full scope if functionalities of a Laboratory Execution System (LES).


Workflows are defined and described in Workflow Templates, which can then be instantiated via execution as Workflow Runs. Workflow Templates are authored as YAML files and can be uploaded and shared by any roles within an organisation and collection which have the required privileges. Once uploaded, Workflow Templates exist as resources in a collection and can be executed by any roles with the required privileges. Changes and parameterization of the Workflow Templates is only possible within the degrees of freedom defined and allowed in the YAML file.

The procurement and instantiation lifecycle of Workflow Templates, Workflow Step Templates and Workflow Runs is outlined below: 

Since Workflows are highly customizable and can be arbitrarily complex, this chapter aims at giving a high-level overview of the hierarchical structure and general principles of Workflow templates. It is meant to provide an orientation to the Workflow Template Schema which provides additional detail and functional information. 

YAML-file based templating

As a data serialization language that is both human-readable and machine-readable, YAML is the optimal format to allow the authoring of both simple and complex workflows using a predefined schema for defining appearance, functionality and logic within a workflow.

YAML files can be regarded as a script which is then executed by the Laboperator server as an interpreting engine.

Schema definition

All Workflow Templates have a UUID and a Version which is unique to an organization within Laboperator, meaning that a YAML file with the same UUID and Version cannot be added if the same combination of UUID and Version already exists within the Organization. YAML template files also have a distinct structure which is explained on a high level in what follows.

The complete YAML schema definition for Workflows can be found here.

Dynamic workflows and Workflow steps

In addition to defining entire Workflows within a Workflow Template, modular steps can be defined as Workflow Steps, which can be added to and combined into Workflows both at design time and at run time. Examples for Workflow Templates may i.e. be a dissolution test, where a weighing step for the sample to be dissolved may be represented by a Weighing Step, which may then be re-used within other workflows and protocols. 

Workflow Step templates can be uploaded, managed and executed the same way as Workflow Templates. They also share similar schemata and can be enriched by Workflow elements in the same way. 

Details on the schema definitions can be found here:

Design-time loading of Workflow Steps

When designing a Workflow Template as a YAML file, Workflow Steps can be added to the Workflow Template by referencing the UUID and Version as the unique identifiers of a Workflow Step Template. All properties of the Workflow Step Template are then defined in a separate unique resource representing the Workflow Step Template.

When running a Workflow Run with an underlying Workflow Template to which a Workflow Step Template has been referenced, it is required that the executing operator has the access and privileges required to load and execute the template, otherwise, an error will be raised.

Additional details on design-time loading of Workflow Steps can be found in the  AddStep Events and Options schema definitions.  

Run-time loading of Workflow steps

At run time, Workflow steps which have previously been uploaded and shared as Workflow Step Templates within an Organization or Collection can be appended (i.e. added to the end) to a Workflow Run that is not finalized or locked. 

Workflow template structure and hierarchy

On a high level, a Workflow Template YAML file can be divided in three parts: Header, Content Elements, Step Definitions and Flow.

The YAML file header contains all workflow metadata metadata that is summarized in the Info Section schema.

Content Elements

On a high-level, Content Elements comprise all Workflow elements which harbor data in the forms of Fields, Arrays and Tables. Once defined at this hierarchical level, they are available as global variables in the entire workflow.

Step Definitions

Step definitions list the different steps, in which all the user interface (UI) Elements encapsulated which make the data visible and controls available to the user. These include, but are not limited to images, buttons, visualization elements like gauges or line graphs, input fields, dropdown menus and many more. Workflow Steps are also usually the place where behaviors (consisting of triggers and actions) are managed as well as calculations and scripts. 

Within steps, variables can also be locally defined as Fields. Locally defined Fields are not available outside the scope of a step. 


In the Flow section, the Workflow Template YAML file defines the sequential order in which the Workflow Steps in the previous sections are executed during the Workflow Run. Conditional and branching logic can be defined in the flow section as well.

Additional information can be found in the Flow Section schema description. 

Workflow elements

This chapter summarizes a high-level overview of visual, functional, logic and UI elements that can be utilized within a Workflow Template YAML file. For a complete overview and additional details, please refer to the Laboperator Workflow Schema Index. 

Workflow ElementHigh-level descriptionSchema Reference
FieldsFields can be used on a global level and within Step Definitions to store variables and data points. Formatting options exist and they can be used as variables, inputs and display option.Link
Context InfoContext Info can be used to display static and dynamic information in a viewport which is available during the entire Workflow and can be collapsed and expanded.Link
Navigation ElementsNavigating to the previous or next step, repeating steps Link 
Media & ContentDifferent media (i.e. images and videos) as well as in-built data displays (i.e. gauges) can be displayed in a Workflow Step or SubstepLink Media 
BehavioursBahaviours can be used to execute actions (i.e. send command to device, send alert, next step etc.) in response to triggers (i.e. temperature above threshold, button pressed, step started etc.) A complete list of available actions and triggers can be found in the linked schema description. Link Triggers
Link Actions 
AlertsAlerts can be raised as an action and can be defined in terms of broadcasting channel according to the linked schema.Link
WebhooksWebhooks can be fired off as an action as a response to a trigger. Webhook URLs have to be authorized by an organisation administrator.Link
TimersTimers can be used as countdown or as forward counting timers. They can both be controlled by triggers, and can trigger actions by themselves.Link
ScansRegistered scanners can set off triggers in workflows as well in addition to acting as a keyboard.
CalculationsArithmetic calculations can be used as part of a script field to calculate values from constants and values from other fields.Link
ButtonsButtons can be used to manually trigger actions within a workflow.Link

Flow and flow control

In the Flow Section of the Workflow Template YAML file, the sequential flow of steps and substeps as defined in the Step descriptions section can be defined as described in the Flow Section Schema.

Additional options for conditional flow and loops are listed in a high-level overview below. 

Option DescriptionReference
Sequential FlowAs a default option, sequential flow describes in the sequential order in which steps defined within the workflow or loaded into the workflow are executed.
Parallel FlowParallel flow allows the parallel execution of nested sequences. Additional information can be found in the linked schema.Link 
While FlowWithin a While Flow, steps or sequences of steps can be repeated as long a predefined condition is met. More details are described in the linked schema. Link 
Loop FlowWithin a While Flow, steps or sequences of steps can be repeated until a predefined condition is met. More details are described in the linked schema. Link
If-Then-Else FlowAn IF-Then-Else Flow allows the conditional branching of sequential flow. Additional details can be found in the linked schema.Link
For-Each FlowA For-Each Flow repeats a certain sequence with a predefined set of conditions, either a series of integers or a predefined data array. Additional details can be found in the linked schema. Link For-Each Integer
Link For-Each Array