---
title: Advanced Workflow Topics
slug: advanced-workflow-topics
docTags: 
createdAt: 2026-01-09T06:49:54.000Z
---

## Workflow Execution

### Execution Process

Workflow execution follows this process:

1. **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()`)
2. **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
3. **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)
4. **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
5. **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:

```text
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:

1. Select the stage
2. Toggle the **Disable** option
3. 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

:::hint{type="warning"}
**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 Actions](docId\:TD4jAiFtmXeKOumFYJWv9) 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.

***