Go-To / Jump-To Node for Workflow Reusability

Introduce a “Go-To” or “Jump-To” node in the workflow builder that allows users to jump from one part of the flow directly to another node elsewhere in the workflow. This would enable reuse of common segments without duplicating steps.

Description:
In many workflows, certain segments of the process are repeated multiple times under different conditions. Currently, to reuse these segments, users must duplicate the same steps at each place, increasing maintenance overhead and complexity.

A “Go-To” node placed at the end of a segment would let users connect that node to another part of the workflow — effectively jumping to and continuing the flow from the connected node. The condition for jumping can be based on the previous step’s outcome or any other logic.

Use Case Example:
Consider an account sign-up process with two branches:

  • Personal email signup branch

  • Work email signup branch

After capturing user info on either branch, the workflow needs to run an account-creation segment. Instead of duplicating the account-creation steps in both branches, a “Go-To” node can be used at the end of each branch to jump to a single account-creation segment node.

This ensures:

  • The account-creation flow is created once and maintained in one place.

  • The workflow remains clean and easier to modify.

  • Logic reuse reduces errors and improves consistency.

Benefits:

  • Simplifies complex workflows by avoiding duplication

  • Enhances maintainability and scalability of flows

  • Enables modular workflow design with reusable segments

  • Reduces chances of inconsistencies and bugs

Additional Notes:

  • The “Go-To” node should visually indicate it leads to another part of the flow.

  • The system should prevent circular jumps that cause infinite loops unless explicitly allowed.

  • Ability to add conditions on when to jump would increase flexibility.


This feature will greatly improve workflow efficiency by enabling modular design and reuse of common logic blocks without redundancy.

Having said that, I am aware of the sub-flows, but creating and managing a sub‑flow in a separate section, then calling and updating that particular sub‑flow, is slightly difficult for my use case. If you are building the flow rapidly, you can use the same trigger input or the same flow that runs across the journey and can be reused. A sub‑flow also needs an input trigger, sample data, or something similar. So, if this is possible within a flow, it will directly increase efficiency.

1 Like