Decision

Evaluates an expression and return True/False

Last published at: March 27th, 2026

Decision Step

Description:

The Decision workflow step evaluates the configured condition and returns either True or False. You can then use the result to control the direction of workflow execution.

The step supports:

  • Defining a condition to evaluate.
  • Entering the condition as multiline text.
  • Evaluating workflow conditions as part of process automation.
  • Routing the workflow through a True or False path.

 

Inputs

  • Condition – The Condition to evaluate property specifies the condition or expression that the Decision step evaluates.
 

 

Returns

  • True – The True return path can be connected to the workflow activities that should execute when the configured condition evaluates to True.
  • False – The False return path can be connected to the workflow activities that should execute when the configured condition evaluates to False.
 

 

Usage:

The Decision step is typically placed in a workflow where the process needs to evaluate a condition before deciding which activity should execute next.

A typical workflow pattern is:

Get Data → Decision → Branch

The condition can evaluate information available to the workflow and determine which path to follow.

The Decision step can be used to:

  • Check workflow values.
  • Evaluate business conditions.
  • Determine approval or rejection paths.
  • Branch based on status.
  • Route processing based on numeric values.
  • Determine whether additional processing is required.
  • Control subsequent workflow activities.
  • Implement conditional workflow logic.

 

 

Typical Workflow Suggestions:

Check an Approval Condition

Use the Decision step to determine whether a request has been approved.

Example:

Submit Request
      |
      v
Evaluate Approval
      |
      v
   Decision
    /    \
  True   False
   |       |
   v       v
Process   Reject
Request   Request
An illustrative condition could be:
ApprovalStatus = "Approved"
The exact expression syntax should be confirmed for the FlowWright environment.

 

Route Based on Request Amount

Use the step to determine which processing path should be followed based on an amount.

Example:

Get Request
     |
     v
   Decision
   /      \
High      Normal
Value     Value
 |          |
 v          v
Manager    Standard
Approval   Processing
An illustrative condition could be:
RequestAmount > 10000
 

Check a Status Value

A workflow can use the Decision step to branch according to the current status of a business process.

Example:

Retrieve Status
      |
      v
    Decision
     /    \
Approved   Pending
   |         |
   v         v
Continue   Wait/Review
An illustrative condition could be:
Status = "Approved"
 

Determine Whether Additional Processing Is Required

Use the Decision step to determine whether a workflow needs to perform an additional processing stage.

Example:

Process Data
     |
     v
   Decision
   /      \
Required  Not Required
  |           |
  v           v
Additional   Continue
Processing   Workflow

 

Validate a Numeric Value

The Decision step can be placed after an activity that calculates or retrieves a numeric value.

Example:

Calculate Score
      |
      v
    Decision
     /    \
Pass       Fail
 |           |
 v           v
Continue   Review
An illustrative condition could be:
Score >= 80

 

Check Whether a Task Is Complete

Use the step to determine the next workflow path based on a task or process status.

Example:

Check Task
    |
    v
 Decision
  /    \
Done   Not Done
 |        |
 v        v
Continue  Wait/Review
The exact condition used depends on the values available to the workflow.

 

Route Based on Customer Information

Use a Decision step after retrieving customer or account information.

Example:

Get Customer Data
       |
       v
     Decision
     /      \
Enterprise  Standard
    |          |
    v          v
Enterprise   Standard
Process      Process
An illustrative condition could be based on a customer classification value.

 

Check a Boolean Condition

A Boolean value can conceptually be used to determine the workflow path.

Example:

Retrieve Data
     |
     v
   Decision
   /      \
 True     False
  |         |
  v         v
Process   Skip
For example, a condition could conceptually evaluate a Boolean workflow value.

The XML does not specify the exact syntax for Boolean expressions.

 

Implement Approval Routing

Use the Decision step after an approval-related activity to determine whether the workflow should continue or follow an alternative route.

Example:

Submit for Approval
        |
        v
     Decision
      /    \
 Approved  Not Approved
    |          |
    v          v
Complete     Rework
Process      Request

 

Check a Processing Result

Use the step after another workflow activity has generated or calculated a result.

Example:

Process Input
      |
      v
Evaluate Result
      |
      v
    Decision
    /     \
Success   Other
  |         |
  v         v
Continue   Handle Result
This lets the workflow split subsequent processing based on the evaluated condition.

 

Conditional Notification

A Decision step can determine whether to send a notification.

Example:

Process Request
      |
      v
    Decision
    /     \
Attention  No Attention
Required   Required
   |           |
   v           v
Send         Continue
Notification

 

Conditional Document Processing

Use the step to determine whether a document requires additional processing.

Example:

Read Document
      |
      v
    Decision
    /     \
Requires   Does Not
Processing Require
   |          |
   v          v
Process     Continue
Document

 

Route Workflow Based on Multiple Conditions

Multiple Decision steps can be chained when a workflow needs to evaluate more than one condition.

Example:

                 ┌── True ──> Path A
                 |
Decision 1 ──────┤
                 |
                 └── False ─> Decision 2
                                  |
                            ┌─────┴─────┐
                          True        False
                           |             |
                           v             v
                         Path B        Path C
This pattern can be useful when different business rules need to be evaluated sequentially.

 

Conditional Cleanup

A Decision step can determine whether to perform cleanup activities.

Example:

Complete Processing
        |
        v
      Decision
      /      \
Cleanup     Keep Data
Required
   |           |
   v           v
Cleanup     Continue

 

Example:

Let’s build and execute the “decisionDef” example.             

  • Create a new process definition called “decisionDef" and open it in Designer mode. 
  • Drag the “UpdateVariable and Decision” steps to the canvas. 
  • Connect the dots between the “Start” and other steps, as shown above.
  • Select the line between the steps to configure the “Connection Properties”. The default property values are “None, True, False, Error, and Evaluate”. Depending on the step’s purpose, you can configure additional values.
  • Define a variable or a global to store the result. 
  • Click the “updateVariable” step to configure its “Required” properties. Enter a name for the step, then click Save. Note: Click the "AI Predict" button to have Copilot add new process steps that match your process description. 

 

  • Click the “updateVariable” step to configure its “Optional” properties. Set the value of “variable.POAmount”. Select “No” if the variable value is not a C# expression. Click the Save button. 

 

  • Click the “decision” step to configure its “Required” properties, as shown below. Then click the connection line to configure the True and False process paths. Click the Save button. Note: Click the "AI Predict" button to have the Copilot add new process steps that match your process description. 

 

  • Click the "Condition to evaluate" field. Press Alt+E to open the Expression Builder. This utility lets you build and validate expressions, as shown below. Copy the expression to the clipboard, then paste it into the input field.

 

  • Examples of conditions to evaluate: 
    (1) Variable.number + 10 >100  
    (2) Global.testNumber + 100 / Variable.colNum >=1000
    (3) Variable.data + "test" == “Apptest”
    (4) Global.hasData == 1

     
  • The “Logging” configuration is necessary for documentation and also measures workflow progress and percent complete. This is achieved by configuring the step state and percent fields individually, as shown below. Configure the “Logging” using the following properties.

 

  • Save the process definition, create a new instance, and execute it. Render the process instance and click the Decision step to view its properties. When the workflow reaches the Decision step, FlowWright evaluates the configured condition and provides the corresponding True or False workflow path. The XML explicitly defines these two return values. Verify:
    • The configured condition.
    • Any workflow values referenced by the condition.
    • The True workflow path.
    • The False workflow path.
    • The resulting workflow behavior.

 

Tips:

  • Keep the condition clear and easy to understand.
  • Use meaningful workflow variable names when constructing conditions.
  • Test the condition with representative data.
  • Test both the True and False paths.
  • Verify that all values referenced by the condition are available when the step executes.
  • Place the Decision step after the activities that provide the values required by the condition.
  • Use separate Decision steps when multiple business rules need to be evaluated independently.
  • Avoid unnecessarily complex conditions when simpler workflow branching can achieve the same result.
  • Document business rules that are implemented through Decision conditions.
  • Test boundary values for numeric conditions.
  • Test conditions with missing or unexpected values where applicable.
  • Verify the resulting workflow path during process-instance execution.
  • Update dependent conditions when workflow variable names or business rules change.
  • Consider connecting both return paths to explicit downstream activities rather than leaving a branch without a defined purpose.
  • Do not assume a particular expression syntax, operator set, case-sensitivity behavior, or function support unless confirmed by the FlowWright implementation.
  • Do not assume how null, empty, invalid, or incompatible values are handled unless confirmed by the implementation.

 

Definition Sample:

You may download the sample definition(s) from the link provided and later import them (drag-and-drop) into your FlowWright Process Definition (XML file) or Form Definition (HTML file) page.

Note: After importing a sample, verify and complete any missing configuration, including:

  • Condition to evaluate.
  • Workflow Variable references used by the condition.
  • Any environment-specific values.
  • Downstream True workflow path.
  • Downstream False workflow path.
  • Activities that provide values required by the condition.
  • Any required logging configuration.

After verifying the configuration, save the Process Definition before execution.

Click here to download the sample file.