---
title: Advanced Workflow Topics
slug: turbine-user-guide/advanced-workflow-topics
docTags: 
createdAt: 2026-01-09T06:49:54.011Z
---

## 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, etc.
   - **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 won't 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:**

- Don't 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 won't 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 won't 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 won't 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 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.

***

## Related Documentation

- [Workflow Overview](./workflow-overview.md) - Introduction to workflow concepts
- [Getting Started with Workflow](./getting-started-with-workflow.md) - How to access and use the workflow builder
- [Creating Conditions](./creating-conditions.md) - Detailed guide on creating conditions
- [Workflow Actions](./workflow-actions.md) - Complete guide to all workflow action types
- [Workflow Best Practices](./workflow-best-practices.md) - Design patterns and best practices
- [Troubleshooting Workflows](./troubleshooting-workflows.md) - Common issues and solutions