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, 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) 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 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 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 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