Condition

The Condition task is a critical component in OSPROV's workflow builder that enables dynamic workflow routing based on data-driven decisions. It allows you to create branching paths in your workflows, directing submissions down different routes based on specific conditions, without requiring user interaction.

Purpose

The Condition task is designed to:

• Create branching paths in workflows based on submission data
• Implement business rules for automated decision-making
• Route workflows differently based on specific criteria
• Enable dynamic workflow behavior without custom code
• Automate decisions that would otherwise require manual evaluation

Adding a Condition Task to Your Workflow

Basic Setup

1. In the Workflow Builder, drag the Condition task from the task palette onto the canvas
2. Click on the Condition task to open its configuration panel
3. Configure the following required settings:
   • Conditions to be fulfilled: Build or enter the logical expression that will be evaluated
   • Title for process: Enter a descriptive title that will appear in the submission history
   • Label for status: (Optional) Override the default status label

Condition Builder

By default, the condition is configured using the visual condition builder — a structured form where each row represents one condition clause. Each row contains:

• Field: The form field to evaluate (supports smart-tag picker to select available fields)
• Operator: The comparison to apply (see table below)
• Value: The value to compare against (hidden for operators that do not require one)

Operator	Description
equals	Strict equality (===)
does not equal	Strict inequality (!==)
is greater than	Numeric greater than (>)
is less than	Numeric less than (<)
is greater than or equal to	Numeric greater than or equal to (>=)
is less than or equal to	Numeric less than or equal to (<=)
contains	Field value contains the given substring
does not contain	Field value does not contain the given substring
is empty	Field value is an empty string (no value required)
is not empty	Field value is not an empty string (no value required)
is checked	Checkbox field is checked (no value required)
is not checked	Checkbox field is not checked (no value required)

When you have multiple condition rows, an AND / OR selector appears between rows so you can combine them with either conjunction. Mixed AND/OR rows are serialized without grouping parentheses — if you need explicit grouping, use Advanced mode instead.

Click Add Condition to add another row. If there is more than one row, each row shows a remove button.

String values are auto-quoted — type yes and the system stores it correctly as 'yes' automatically.

Advanced Mode

For complex expressions that cannot be represented in the builder, click the Advanced button at the top-right of the condition field to switch to a free-text input.

You can use:

• Standard PHP strict comparison operators (===, !==, <, >, <=, >=)
• strpos() for substring checks
• Logical operators (&&, ||, !)
• Parentheses for grouping
• The smart-tag picker to insert field references

The builder and advanced mode share the same underlying value. Switching back from advanced mode reloads the builder if the expression can be parsed; otherwise it stays in advanced mode.

When viewing a condition task in read-only mode, such as on a submitted workflow, the Advanced toggle, Add Condition button, smart-tag buttons, and row remove buttons are hidden, and all inputs are disabled.

For supplementary forms, reference fields as forms.N.field_name, for example forms.2.amount.

Field references must be wrapped in square brackets. The system replaces [field_name] with the actual submission value at runtime. Use the smart-tag picker to insert them correctly.

Examples of valid advanced expressions:

• [amount] > 1000
• [department] === "IT"
• [forms.1.approved] === '1' && [amount] < 5000
• [risk_score] >= 75 || [expedited] === '1'

Workflow Branching

In the workflow builder canvas, the Condition task creates two output connectors:

• The right connector (output 1) represents the path taken when the condition is true
• The left connector (output 2) represents the path taken when the condition is false

Connect different tasks to each of these connectors to create branching paths in your workflow. The workflow automatically follows the appropriate path based on the condition evaluation.

Merging Branches Back Together

After the true and false branches each follow their own path, they can be merged back into a single task further down the workflow. The merge point must be a task that comes after the branch tasks — you cannot connect both condition outputs directly to the same task.

The typical shape is:

Condition → [true] Task A ──┐
          → [false] Task B ──┴→ Merge Task → ...

To create a merge task, connect outputs from two different branch-end tasks to the same downstream task node.

• The first connection made becomes the primary connection
• The second connection is assigned to the merge slot
• In the canvas, the merged task is shown with purple styling to make it visually distinct

The workflow proceeds from the merge task as soon as either branch reaches it — it does not wait for the other branch. The submission's branch state is reset at the merge point so the workflow continues normally from there.

You can remove either branch connection at any time. If the primary connection is removed, the merge connection is automatically promoted to become the primary.

Advanced Settings

Visibility Settings

• Hide from submission history: When checked, prevents this condition task from appearing in the submission history
  • Useful for keeping the submission history focused on user actions
  • The condition evaluation still occurs, but is not visible in the history
  • Helps reduce clutter in complex workflows with many tasks

How Condition Tasks Work

When a workflow reaches a Condition task:

1. The system retrieves the condition expression from the task configuration
2. Any field references in the condition are replaced with actual values from the submission data
3. The condition is evaluated to either true or false using PHP's eval function
4. Based on the result:
   • If true, the workflow follows the right branch
   • If false, the workflow follows the left branch
5. The workflow automatically proceeds to the next task on the selected branch

If the branch eventually leads to a merge task, meaning a task connected from both branches, the workflow continues from that merge task regardless of which branch was taken.

Unlike action tasks such as Approve, Review, or Process, Condition tasks:

• Do not appear in users' task lists
• Do not require any user action to complete
• Execute automatically and immediately
• Control workflow routing based on data-driven decisions

Use Cases

Amount-Based Routing

Route workflows based on monetary values:

• Send high-value purchases to senior management for approval
• Route different expense categories to appropriate departments
• Apply different approval processes based on budget impact
• Implement multi-tier approval thresholds

Risk-Based Routing

Implement risk-based decision making:

• Route high-risk submissions for additional review
• Apply different validation requirements based on risk scores
• Implement enhanced due diligence for certain scenarios
• Skip unnecessary steps for low-risk submissions

Department-Specific Processes

Create department-specific workflow branches:

• Route IT requests to the IT department
• Send HR-related submissions through HR-specific processes
• Apply different approval requirements by department
• Implement department-specific validation rules

Status-Based Decisions

Route based on previous task outcomes:

• Create different paths for approved vs. rejected submissions
• Implement special handling for exceptions
• Route based on review feedback
• Apply different processes based on submission quality

Conditional Steps with Common Continuation

Use branch merging to add optional steps without duplicating the rest of the workflow:

• Include an extra approval step for high-value requests, then merge both paths into the same final processing task
• Route through a risk review for flagged submissions, then merge back into the standard completion path
• Skip a document generation step for simple cases, then continue at the same notification task

Best Practices

1. Use the condition builder: The visual builder reduces syntax errors and makes conditions easier to read and maintain
2. Reserve advanced mode for complex logic: Switch to free-text only when the builder cannot express what you need, such as grouped parentheses
3. Descriptive task titles: Use titles that clearly indicate the decision being made
4. Consistent branching: Use consistent conventions for true/false routing, such as always using right/true for the approval path
5. Merge to avoid duplication: If both branches eventually need the same downstream tasks, connect them to a merge node rather than duplicating those tasks
6. Error handling: Consider what happens if referenced fields are missing or null
7. Testing: Test conditions with different data scenarios to ensure they route as expected
8. Field validation: Ensure that fields referenced in conditions will contain appropriate data types

Troubleshooting

Unexpected Routing

If workflows are not routing as expected:

• Verify that the condition expression is correctly built (check each row in the builder)
• Check that referenced fields exist in the submission data
• Test the condition with different values to understand its behaviour
• Ensure that both branches are properly connected to subsequent tasks
• Check for typos in field names (they are case-sensitive)

Expression Falls Back to Advanced Mode

If you open the condition builder and it shows in advanced mode instead of the visual builder:

• The saved expression is too complex for the builder to parse
• This is expected for expressions with nested parentheses or non-standard patterns
• You can simplify the expression and rebuild it in the visual builder, or continue editing in advanced mode

Syntax Errors

If the condition task fails due to syntax errors:

• Check for proper syntax in the condition expression (use the builder where possible)
• Ensure string values are properly quoted in advanced mode
• Verify that field names are correctly referenced
• Test simpler versions of the condition to isolate the issue

Missing Field References

If the condition references fields that do not exist:

• Verify the exact field names in your forms using the smart-tag picker
• For supplementary forms, ensure the form sequence number is correct
• Check for typos in field names
• Consider adding default values to forms to handle missing data
• Use the system logs to identify specific error messages

Merge Task Not Continuing

The merge task executes as soon as either branch reaches it — it does not wait for the other branch. If the workflow appears to stop at the merge task:

• Check that both branch-end tasks are connected to the merge task in the canvas. The merge task should be shown with purple styling
• Verify that the second connection was added after the first. Only the second connection assigns the merge slot
• If a connection was removed and re-added, confirm the merge slot was reassigned correctly. The merge task should still appear in purple
• Confirm the merge connections come from branch tasks, not directly from the Condition node itself. Direct Condition-to-merge connections are not supported

Related Features

• Transform Tasks: Prepare data before condition evaluation
• Hook Tasks: Alternative for more complex conditional logic
• Multiple Conditions: Chain multiple condition tasks for complex decision trees

Summary

The Condition task is a powerful component in OSPROV's workflow builder that enables dynamic, data-driven routing of workflows. The visual condition builder makes it straightforward to configure conditions without writing expressions manually, while advanced mode remains available for complex cases. Branch merging allows both the true and false paths to rejoin a common continuation point, avoiding the need to duplicate downstream tasks.

Unlike action tasks that require user interaction, condition tasks execute automatically and control workflow routing based on data evaluation. This makes them ideal for implementing business rules, creating different processes based on submission characteristics, and automating routine decisions throughout your business processes.