Overview

Workflows in Workbench are directed acyclic graphs (DAGs) - a sequence of dependent processing operations that can only be performed in one direction, with no closed (infinite) loops.

Declarative syntax

Workflows are expressed using Workbench Workflow Definition Language (WWDL). WWDL is a declarative workflow language - it expresses what operations need to be performed, but leaves the how up to the individual workflow nodes at execution time. This offers two advantages versus an imperative workflow:

Lower complexity - provided the user is able to correctly express the business logic they wish to automate, the user doesn't need to understand Python syntax - or even how Workbench has been constructed.
Language agnostic - although Workbench is a Python package, this may not always be the best language choice for all users - particularly those with legacy systems or established teams working in other languages. A declarative language would allow users to develop their own workflow orchestrators / runners in other coding languages that can consume WWDL - making this a good choice for businesses that want to document their data processing workflows today without worrying about vendor lock-in tomorrow.

Workflow runners

Workbench offers two methods for running workflows - basic and advanced:

Mode	Intended use	Limitations
Basic	Running simple workflows locally, for development or debugging purposes.	Only supports Workbench processing units (not functions) as workflow nodes Branching not supported - nodes must be a single, linear path Not declarative - workflows must be defined using workflow constructor classes
Advanced	Running complex workflows locally or in the cloud.	Must have an Azure Table Storage resource for writing log messages Requires understanding of WWDL

More information is provided in related sub-sections within this guide.