Skip to main content

V1 vs V2 Workflow Engines

Workflow86 currently supports two workflow execution modes:

  • V1: legacy join behavior
  • V2: explicit-path behavior

You will see the mode as a V1 or V2 badge in the workflow UI.

Quick comparison​

AreaV1V2
Merge behavior (multiple inputs into one component)Implicit join: downstream components wait for all input paths by defaultExplicit merge control with Merge Workflow Paths
Parallel path controlMostly implicitExplicit and configurable (ALL, ANY, custom combinations)
Loop behaviorUses legacy loop patterns that rely on Trigger from a Workflow and Trigger another Workflow with loop mode optionsBackward connections are allowed and handled as loop edges
Design styleLegacy behavior optimized for existing workflowsNew behavior optimized for explicit, predictable path control

Why V2 exists (and why it is better)​

V2 was introduced to make workflow execution behavior more explicit, especially in branching and merging workflows.

In V1, many workflows rely on implicit behavior (for example, hidden wait-for-all joins on incoming connections). That is convenient for simple cases, but it can become harder to reason about as workflows grow.

V2 improves this by making control-flow intent clearer in the canvas:

  • Merge behavior is explicit with Merge Workflow Paths, instead of being inferred.
  • Parallel-path logic is more flexible (ALL, ANY, and custom combinations).
  • Loop modeling is more natural with native loop edges.
  • Execution behavior is easier to debug because control points are visible in the graph.

Trade-off: V2 gives more control, but it also expects workflow authors to model merge points intentionally where needed.

Merge behavior difference​

How this example runs in V1​

  • Next component runs only after Path A and Path B have both run.
  • This is the legacy implicit wait-for-all join behavior.

If Path A completes first, Next component does not run yet. It waits until Path B also completes, then runs once with data available from both incoming paths.

How the same example runs in V2​

  • The same graph can run Next component when Path A or Path B runs.
  • To make merge behavior explicit and predictable, model the join with Merge Workflow Paths.

If Path A completes first, Next component can continue immediately. In other words, without an explicit merge node, the same shape no longer guarantees a wait-for-both-paths join.

Preserving V1 behavior in V2​

If you want to keep the original V1 wait-for-all behavior in V2, insert a Merge Workflow Paths node and set it to ALL.

With this setup, Path A and Path B feed into Merge Workflow Paths ALL, and only when both are complete does the flow continue into Next component. This recreates the original V1 semantics while keeping merge behavior explicit.

Merge Workflow Paths can be configured as ALL, ANY, or custom combinations based on your desired behavior.

Loop behavior difference​

In V1, loops are modeled with legacy loop patterns that require Trigger from a Workflow and Trigger another Workflow components. In practice, you loop by routing back through those trigger components (with loop mode settings), rather than drawing a direct backward edge on the canvas.

In V2, loops are native to the graph model: backward connections are treated as loop edges.

When to use V1 vs V2​

Use V1 when:

  • You are maintaining an older workflow that already behaves correctly
  • You do not need explicit merge modeling changes right now

Use V2 when:

  • You are creating new workflows that branch and merge often
  • You want explicit and readable merge logic
  • You want loop behavior modeled directly with loop edges

Migration notes​

  • Converting a workflow to V2 may insert merge nodes to preserve behavior.
  • Migration creates a new workflow version, so you can roll back via version history if needed.
  • Test merged-path and loop-heavy workflows after migration.

For practical examples, see: