Docs
Node Logic

Node Logic

img_8.png Node Logic provides powerful ways to wrap and extend your node's behavior, enabling advanced control mechanisms for flow control, conditional routing, and iterative processing. These logic options help you build more dynamic, responsive, and flexible workflows.

💡 Tip: Node Logic is useful for flow control, conditional routing, and iterative refinement. Add logic to your nodes to enhance workflow flexibility and enable dynamic execution paths.

Overview

When configuring a node, you can add logic to control how the node executes and routes execution through your workflow. The available logic options include:

  • Fallback - Automatically switch to a backup node configuration on timeout or failure
  • Retry - Automatically retry node execution with configurable attempts and delays
  • Go Back - Conditionally route execution back to a previous node based on output data
  • Parallel - Execute multiple node configurations simultaneously
  • A/B Test - Split traffic between two node configurations with configurable percentages

1. Fallback

Fallback logic enables automatic failover to a backup node configuration when the primary node times out or fails. This ensures your workflow continues executing even if the primary node encounters issues.

When to Use Fallback

  • When you need high availability and reliability
  • When working with nodes that may have variable response times
  • When you want to ensure your workflow doesn't fail due to node unavailability

Configuration

When you select Fallback, you can configure:

  • Config A (Primary Logic) - The primary Logic configuration that will be attempted first
  • Config B (Fallback Logic) - The backup Logic configuration used if Config A fails or times out
  • Timeout - The maximum time to wait for Config A before switching to Config B

How It Works

  1. The system attempts to execute Config A (your primary node configuration)
  2. If Config A times out (based on your timeout setting) or fails, the system automatically switches to Config B
  3. The result from the successful configuration (either A or B) is used to continue the workflow

⚠️ Note: Make sure Config B uses a different node or configuration that's more reliable or faster, even if potentially less optimal.

2. Retry

Retry logic automatically retries node execution when it fails, helping you handle transient errors and network issues gracefully.

When to Use Retry

  • When dealing with intermittent network issues or API rate limits
  • When you want to automatically recover from temporary failures
  • When working with nodes that may occasionally timeout

Configuration

When you select Retry, you can configure:

  • Max Retry Attempts - The maximum number of times to retry the node execution (e.g., 3, 5, 10)
  • Delay - The time to wait between retry attempts (e.g., 1 second, 5 seconds)

How It Works

  1. The system attempts to execute the node
  2. If the execution fails, it waits for the specified Delay period
  3. The system retries the execution
  4. This process repeats until either:
    • The execution succeeds, or
    • The maximum number of retry attempts is reached

💡 Best Practice: Set appropriate delay values to avoid overwhelming the node API and to respect rate limits.

3. Go Back

Go Back logic allows you to conditionally route execution back to a previous node in your workflow based on the node's output data. This enables dynamic flow control and iterative refinement.

When to Use Go Back

  • When you need to refine or reprocess data based on node output
  • When implementing iterative workflows that require multiple passes
  • When you want to conditionally loop back to previous processing steps
  • When you need to retry a process until certain conditions are met

Configuration

When you select Go Back, you can configure:

  • Condition - A condition based on the output data that determines when to go back
  • Target Node - The specific node to route execution back to when the condition is met
  • Action - The action to trigger when routing back (e.g., re-execute, update context)

How It Works

  1. The node executes and produces output
  2. The system evaluates the Condition against the output data
  3. If the condition is met, execution routes back to the specified Target Node
  4. The target node re-executes with the updated context
  5. If the condition is not met, execution continues to the next node in the flow

⚠️ Warning: Be careful to avoid infinite loops. Ensure your conditions can eventually be false, or set maximum iteration limits.

Example Use Cases

  • Quality Check Loop: Route back to a processing node if output quality doesn't meet certain criteria
  • Data Validation: Return to a data transformation node if validation fails
  • Iterative Refinement: Loop back to a model node to refine output until it meets specific requirements
  • Retry Logic: Automatically retry a node's operation until success conditions are met

4. Parallel Execution

Parallel logic executes two node configurations simultaneously, allowing you to compare results or combine outputs from different Logic.

When to Use Parallel

  • When you want to compare outputs from different Logic
  • When you need to combine results from multiple node configurations
  • When you want to improve performance by running Logic concurrently

Configuration

When you select Parallel, you can configure:

  • Config A - The first Logic configuration to execute
  • Config B - The second Logic configuration to execute
  • Both configurations execute simultaneously

How It Works

  1. Both Config A and Config B start executing at the same time
  2. The system waits for both configurations to complete
  3. You can access results from both configurations in subsequent Logics
  4. Results are typically available as separate outputs or can be combined based on your workflow logic

💡 Tip: Parallel execution can significantly reduce total execution time when you need results from multiple Logic, as they run concurrently rather than sequentially.

5. A/B Testing

A/B Testing logic allows you to split traffic between two Logic configurations with configurable percentages, enabling you to test and compare different Logic setups.

When to Use A/B Testing

  • When you want to compare the performance of different Logic configurations
  • When testing new Logics or configurations against existing ones
  • When you need to gradually roll out new Logic configurations

Configuration

When you select A/B Test, you can configure:

  • Config A - The first Logic configuration
  • Config B - The second Logic configuration
  • Traffic Split - The percentage distribution between Config A and Config B
    • Config A Percentage - e.g., 40% of requests go to Config A
    • Config B Percentage - e.g., 60% of requests go to Config B
    • Percentages must total 100%

How It Works

  1. For each execution, the system randomly selects Config A or Config B based on the configured percentages
  2. If Config A is set to 40% and Config B to 60%:
    • Approximately 40% of executions use Config A
    • Approximately 60% of executions use Config B
  3. Results from both configurations can be tracked and compared
  4. The system maintains the traffic split distribution over time

📊 Analytics: Use the Logs and Reports tabs to analyze the performance and results of each configuration in your A/B test.

Adding Logic to a Node

To add logic to a node:

  1. Select the node in your flow
  2. Open the Config tab in the right sidebar
  3. Navigate to the LOGIC section
  4. Click on the Logic sub-tab
  5. Click + Add Logic button
  6. Select the logic type you want to add:
    • Fallback (clock icon)
    • Retry (refresh icon)
    • Go Back (back arrow icon)
    • Parallel (parallel lines icon)
    • A/B Test (A/B icon)
  7. Configure the selected logic type with the appropriate settings
  8. Save your configuration

💡 Note: You can combine multiple logic types on a single node for more complex behavior, such as using Retry with Fallback for maximum reliability, or Go Back with conditional checks for sophisticated flow control.

Best Practices

  • Fallback: Always configure a reliable backup node that's faster or more stable than your primary
  • Retry: Set reasonable retry limits and delays to avoid excessive API calls and costs
  • Go Back:
    • Always implement safeguards to prevent infinite loops (e.g., iteration counters, maximum retry limits)
    • Ensure your conditions are well-defined and can eventually evaluate to false
    • Use clear naming conventions for target nodes to make flow logic easier to understand
    • Test your loops thoroughly with various input scenarios
    • Consider adding logging or monitoring to track loop iterations
  • Parallel: Use when you genuinely need both results, as it increases resource usage
  • A/B Testing: Run tests for sufficient duration to gather statistically significant data

Related Resources

Langfuse IntegrationFeedback API

Was this page useful?

Questions? We're here to help

FeedbackEmailTalk to sales

Subscribe to updates