Advanced Workflow Topics

Workflow Execution

Execution Process

Workflow execution follows this process:

Initialization Phase

System loads the workflow configuration

Initializes tracking for workflow execution

Creates a unique workflow run identifier (CurrentWorkflowRunId)

Increments workflow run sequence number

Skips execution if workflow is empty or default (IsDefaultWorkflow())

Recursive Stage Processing Phase

Processes each stage in the workflow tree recursively (recursiveProcess)

For each stage:

Checks if stage is disabled (skips if disabled)

Evaluates all conditions in the stage sequentially

Determines stage validity based on:

Condition evaluation results (AND/OR logic)

Parent stage validity (parentValid parameter)

Stage disabled state

Queues actions for execution:

Regular actions: When conditions are met (valid && parentValid) and stage was not previously executed

Inverse actions: When conditions are no longer met (stage.executed becomes false) for reversion

Condition Evaluation Phase

Each condition evaluates a field value against criteria

Conditions use operators: equals, doesNotEqual, contains, greaterThan, and so on

AND logic (evalType === 'and'): All conditions must be true (stops at first false via early break)

OR logic (evalType === 'or'): Any condition being true is sufficient (stops at first true via early break)

Early exit optimization improves performance (breaks loop when result is determined)

Action Execution Phase

Inverse actions execute FIRST (processed before regular actions to ensure proper precedence)

Then regular actions execute

Actions are processed in order within each stage (forEach loop)

Disabled actions are skipped (!a.disabled check)

SetValue actions: Only execute once per workflow run (tracked in record.actionsExecuted to prevent infinite loops)

When SetValue actions are reverted, their IDs are removed from actionsExecuted tracking

Action Reversion Phase

When conditions become false, previously executed actions are reverted

SetValue actions: Values may persist but actions will not re-execute (ID removed from tracking)

Layout actions: Automatically revert via inverse actions (show becomes hide, hide becomes show)

Field state actions: Reverted to previous state

Execution Order

Important: There is no guaranteed order of execution for conditions across different stages. However:

Conditions within a stage are evaluated in order

Actions are queued during condition evaluation

Actions execute after all condition evaluation completes

Inverse actions always execute before regular actions

Execution Details:

Actions are queued during condition evaluation, not executed immediately

After all conditions are evaluated, inverse actions execute first

Then regular actions execute in order

This ensures proper precedence when actions conflict

Best Practices:

Do not rely on execution order between unrelated conditions

Use nested stages if you need specific execution order

Test workflows thoroughly to ensure expected behavior

Be aware that SetValue actions only execute once per workflow run

Action Reversion

When a condition that was previously true becomes false:

SetValue actions: Values may persist but actions will not re-execute

Layout actions: Inverse actions execute automatically (show → hide, hide → show)

Field state actions: Reverted to previous state

Nested stages: All actions in nested stages are also reverted

How Reversion Works:

When a condition becomes false, the stage is marked as not executed

SetValue actions are removed from execution tracking

Inverse actions are queued to revert previous changes

Layout actions automatically revert (show becomes hide, hide becomes show)

Field state actions revert to their previous state

Example:

If a condition hides a field when Status = "Closed", and the Status changes from "Closed" to "Open":

The inverse action executes (hide → show)

The field becomes visible again

If a SetValue action had set a value, that value may persist but the action will not re-execute

Workflow Run Tracking

Each workflow execution is tracked:

Workflow Run ID: Unique identifier for each workflow execution

Sequence Number: Increments with each execution on the same record

Workflow Version: Tracks which version of the workflow was executed

Start/End Times: Logged for performance monitoring

This tracking enables:

Debugging workflow execution issues

Performance analysis

Audit trails

Workflow run history

Advanced Workflow Concepts

Nested Stages

Create complex workflows by nesting stages:

Stage 1: If Status = "Active"
  ├── Action: Show Active Fields
  └── Stage 2: If Priority = "High"
      ├── Action: Make Fields Required
      └── Stage 3: If Assigned To = Current User
          └── Action: Show Personal Notes

Benefits:

Create hierarchical conditional logic

Organize complex workflows

Enable progressive disclosure

Disabling Stages

You can disable stages without deleting them:

Select the stage

Toggle the Disable option

The stage and its conditions/actions will not execute

Use Cases:

Temporarily disable workflow logic for testing

Keep workflow structure while testing alternatives

Enable/disable features without losing configuration

Default Actions

The Default Actions stage is a special condition type that always evaluates to true. Actions in this stage execute every time the workflow runs. Use it for:

Actions that should always run regardless of other conditions

Initial field setup

Default values

Always-visible fields

Base configuration that applies to all records

Workflow Validation

The workflow builder validates your configuration:

Condition validation - Ensures conditions have required fields and values

Action validation - Ensures actions are properly configured

Error messages - Display validation errors in the workflow builder

Common Validation Errors:

Condition missing field selection

Condition missing comparison value (when required)

Action missing target field

Action missing required configuration

Workflow Validation (above) covers validation in the workflow builder. Record Save Validation (below) covers validation on the record form when users save.

Record Save Validation

When workflow marks a field as required, Turbine validates that field on record save.

Topic	Behavior
Validator refresh	When the record opens and when workflow re-evaluates after field changes
Save trigger	Save and Save and Close run validation after workflow evaluates current conditions
Hidden fields	Fields hidden by Modify Layout are excluded; validators are cleared for hidden fields
Supported field types	Text (including rich text), numeric, date, values list, list, and user/group
Save failure notification	The record has validation error(s)!
26.2.0 change	Workflow-required fields are validated on save without requiring prior field interaction

Starting in Turbine 26.2.0, save validation applies immediately for fields that are optional in Application Builder but required by workflow. For configuration steps and user-visible error behavior, see Workflow ActionsSet Field Required/Optional in Workflow Actions.

Workflow and Applets

When applets are added to applications:

Applet workflow is integrated into the application workflow

Applet conditions and actions execute within the application context

Applet fields are available for conditions and actions

Workflow is updated automatically when applets are added or removed

For more information on applets and workflow integration, see the Applets Documentation.