About Workflow Definitions

A Workflow Definition is a way to group multiple Job Definitions and control the order in which they execute.

Note: In the Classic and Legacy UI, a Workflow Definition is referred to as a "Chain Definition."

Parts of a Workflow Definition

Workflow Definitions can incorporate the following elements.

  • Steps. Each Workflow Definition consists of one or more Steps, each of which can contain one or more Job Calls. Steps execute one after the other, but Job Calls within a Step execute concurrently.

  • Job Calls. A Job Call is a call to execute a Job Definition. Each Job Call must be inside a Step.

    Note: In the Classic and Legacy UI, a Job Definition is referred to as a "Process Definition."

  • Sub-Workflows. You can add a Workflow to another Workflow by dragging it from the Job Call overlay. Once you have added a sub-Workflow, you can expand it by clicking the icon.

  • Conditions. Conditions are additional checks you can use to make sure Job Calls execute at the right time. If a Condition is not met, the Workflow will stop and wait until it is met.

    • Event Conditions let you make a Job Call raise or wait for Events. For example, you can make a Job Call wait until a file arrives in a folder, or until after another Job Call or Workflow completes.

    • Time Conditions let you make a Job Call execute only within one or more Time Windows. For example, you can make a Job Call run only during weekdays.

    Note: In the Classic and Legacy UI, a Condition is referred to as a "Precondition."

  • Decision Points. By default, a Workflow will run its Steps from left to right. Decision Points let you change that.

    • Status Decision Points let you configure Status Handlers. These, in turn, let you control what happens when a Step or Workflow reaches a particular status. For example, if Step 2 goes into Error status, you can make execution skip to Step 5.

    • Time Decision Points let you branch execution based on a Time Window. For example, you can make a Workflow continue its path of execution only during workdays, and on other days, skip to a later Step.

    • If Decision Points let you execute a Step or Job only if certain conditions are met. For example, you can run an alerting Job only if a report file is empty.

Viewing Workflow Definitions

There are multiple ways to view Workflow Definitions.

  • At the root level, the Studio screen lets you view Workflow Definitions in a hierarchical format. You can expand a Workflow Definition to reveal its Steps, and then you can expand a Step to reveal the Job Calls it contains.

  • When you create or edit a Workflow Definition, the Studio displays it in the Workflow Editor. Here, you can edit a Workflow Definition with easy to use drag-and-drop tools.

  • If you click a Workflow in the Monitor screen, it displays in an interactive Runtime View.

Searching in the Workflow Editor

In large or complex Workflows, it can sometimes be difficult to find a particular Job Call, Step, or sub-Workflow. To make this easier, you can click at the bottom right to display a search overlay with a tree view of the Workflow. Enter the name of an Object in the Workflow to see it in the list, then click it to navigate to it in the Workflow Editor.

Creating Workflow Definitions

The Workflow Editor provides an intuitive low-code way to create Workflow Definitions. For more information, see Creating a Workflow Definition.

Note: In RedwoodScript, a Workflow Definition is a JobDefinition of type JOBCHAIN.

Note: If you specify a name for a Workflow and then add sub-Workflows, the Workflow name is used as the default name for child Workflows, with a suffix of _<n> (where <n> is a number).

Executing Workflow Definitions

You can execute a Workflow Definition the same way you execute a free-standing Job Definition: by right-clicking it and choosing Run from the context menu.

Note: If a process in a Step reaches an error state, the Step is also put into an error state. By default, a Workflow aborts if one of its Steps reaches an error state, but you can override this behavior with Status Handlers.

Ignoring Job Calls

By default, a Step waits for all its children, because all Job Calls have StepWaitingOnJob set to true by default. The Step also sets its status according to the status of its children, because all Job Calls have ignoreStatus set to false, by default. You can set the flags individually for a Job Call. Note that when ignoreStatus is set to true, the Step will still wait for the Job Call.

Maximum Restarts

The Maximum Starts value (Process Status tab) determines how often the system may run a Job Definition. The value is decremented after the initial run and with each automatic restart. In other words, a Maximum Starts value of 4 will restart the Job Call 3 times and the total number of runs will be 4. If an Operator intervenes using an action on a Job Call or an Operator Message, for example, then the value is reset to the value in the Job Definition.

Note: The Maximum Starts property on a Step behaves slightly differently as the initial run counts towards the value specified in Maximum Restarts; on Job Calls, the initial run does not count towards the value specified in Maximum Restarts.