Skip to main content

Go To

Goes to a specific Label node in the workflow.

Common Properties​

  • Name - The custom name of the node.
  • Color - The custom color of the node.
  • Delay Before (sec) - Waits in seconds before executing the node.
  • Delay After (sec) - Waits in seconds after executing node.
  • Continue On Error - Automation will continue regardless of any error. The default value is false.
info

If ContinueOnError property is true, no error is caught when the project is executed even if Catch node is used.

Options​

  • Nodes - Check the label nodes you want to jump to

Usage​

The Go To node allows you to specify and jump to a specific Label node in your workflow by its name. You can select a single node or multiple nodes to jump.

How It Works​

The Go To node implements flow control by redirecting execution to a Label node:

  1. During node creation, the Go To node registers itself with all selected Label nodes
  2. When the Go To node receives a message during execution:
    • It processes any delay before execution
    • The message passes through without modification
    • Execution jumps to the registered Label node(s)
  3. The flow continues from the Label node, bypassing nodes in between

Requirements​

  • At least one Label node must exist in the workflow
  • The selected Label node(s) must be configured in the Nodes option
  • Label nodes should be positioned where you want execution to continue

Error Handling​

Error CodeDescriptionSolution
Core.Flow.Stop.ErrOnCreateFailed to parse node configurationVerify node configuration is valid JSON
Core.Triggers.Goto.ErrOnMessageMessage parsing failed during executionCheck that input message format is valid

Usage Examples​

Example 1: Retry Loop for Error Handling​

Create a retry mechanism for failed operations:

[Start] → [API Call] → [Check Response]
              ↓ (if error)
          [Increment Retry Count]
              ↓
          [Check if Max Retries]
              ↓ (if < max)
          [Go To: "RetryLabel"]
              ↓
          [Label: "RetryLabel"] → [API Call] ...

Example 2: Conditional Workflow Branching​

Skip sections of workflow based on conditions:

[Start] → [Check Customer Type]
    ↓ Premium?
[Go To: "PremiumProcess"] → [Label: "PremiumProcess"] → [Special Handling]
    ↓ Regular?
[Label: "RegularProcess"] → [Standard Handling]

Example 3: Early Exit from Loop​

Exit a loop early when a condition is met:

[Loop Through Items]
    ↓
[Process Item]
    ↓
[Check if Target Found]
    ↓ (yes)
[Go To: "LoopEnd"]
    ↓ (no)
[Continue Loop]
    ↓
[Label: "LoopEnd"] → [Process Results]

Usage Notes​

  • When Continue On Error is enabled, errors are not caught even if a Catch node is present
  • The Go To node does not modify the message payload
  • Multiple Go To nodes can target the same Label
  • A single Go To node can target multiple Labels (execution continues at all of them)
  • Jumping to a Label creates a subscription-based message routing
  • Go To creates a non-linear flow, so use with caution to maintain code readability

Tips​

  • Use meaningful names for Label nodes to make flow logic clear (e.g., "RetryStart", "ErrorHandler", "LoopEnd")
  • Avoid creating infinite loops with Go To → Label combinations without exit conditions
  • Document the reason for using Go To with a Comment node for better maintainability
  • Consider using decision nodes before Go To for cleaner conditional logic
  • Be careful with nested loops using Go To - they can be difficult to debug
  • Use Go To sparingly - excessive jumping can make flows hard to understand
  • For complex branching, consider using Sub Flows instead
  • Test thoroughly to ensure Go To logic doesn't create unintended execution paths
  • Label - Required destination marker for Go To jumps
  • Stop - For terminating flow execution
  • Sub Flow - Alternative for complex flow organization
  • Fork Branch - For parallel execution paths