Skip to main content


Create a workflow


varname = workflow IN "category"
workflowStart (phase|workflowEvent|NL|comment)*

workflowStart: WF_START
workflowBody: (workflowEvent|workflowAction|workflowGateway|workflowWorkflow)
workflowEvent: WF_EVENT varname AS "string"
workflowAction: WF_ACTION varname input
workflowGateway: WF_GATEWAY varname input
workflowWorkflow: WF_WORKFLOW varname input
workflowTransition: "name" -> connection

// Workflow phases
phase: phase "name" (retries INT)? (delay INT TIMEUNIT)? (then reschedule)? (external)?
reschedule: reschedule INT TIMEUNIT
fail: fail expression
abort: abort expression


The configuration of a workflow is best done using the workflow GUI in the web portal (Not available yet), but it can also be done in OpenDataDSL code.

Anatomy of a workflow

A workflow has some input, output and exit configuration at the start - just like an action. The input information is passed in via a process or as an object if running the workflow manually.

Workflow Blocks

All workflows have building blocks in them:

  • WF_START - There must be exactly 1 of these, which indicates the start point and it only contains a transition which is the first workflow element that is called
  • WF_ACTION - This is a block which configures a workflow action. You can:
    • define the action transition routing, i.e. the route to take given the transition information when the action completes
    • assign the action input variables from the workflow input or any previous action outputs
    • run the action using the input variables
  • WF_GATEWAY - This block configures a workflow gateway. It is configured in the same way as an action block and is generally used to route workflows according to an expression
  • WF_WORKFLOW - This block configured a sub-workflow, it is configured in the same way as an action - NOTE than any workflow can be used as a sub-workflow
  • WF_EVENT - This is generally used as an end point of a workflow and is used to return the transition information back to the calling application.
Workflow Phase

A workflow can nest its WF_ACTION, WF_GATEWAY and WF_WORKFLOW blocks in a phase.

It is recommended that you use phases in a workflow for the following reasons:

  • It breaks a workflow into distinct sections which get reported in real-time whilst the workflow is executing
  • It allows you to time sections of the workflow
  • Each phase allows for custom configuration of retries, retry delay and rescheduling


wf_xml_extract = workflow in "data-loaders"
// Extract some data
in url as Scalar
exit "success", "failed"

"ok" -> act_extract_xml

phase "EXTRACT"
WF_ACTION act_extract_xml ai
"ok" -> stopok
"failed" -> stopfailed
ai.url = input.url
result = ${action:"#extract_xml"}.run(ai, output)

WF_EVENT stopok as "success"
return "ok"
WF_EVENT stopfailed as "failed"
return "failed"

As a line-by-line breakdown of this workflow

  1. Define a workflow called wf_xml_extract in the category data-loaders
  2. Set a description for this workflow
  3. Define an input variable called url which is a Scalar
  4. Define exit transitions for the workflow as success and failed
  5. Define the workflow start point
  6. Transition to the action named act_extract_xml (the transition name is ignored)
  7. Define a workflow phase called EXTRACT
  8. Define an action block called act_extract_xml with an input variable called ai
  9. Route the “ok” transition to stopok
  10. Route the “failed” transition to stopfailed
  11. Set the url on the action input to be the input url (passed in by the process)
  12. Run the #extract_xml action passing in the ai variable and the global output variable
  13. Define the stopok event as a success transition for the whole workflow
  14. Define the stopfailed event as a failed transition for the whole workflow