Logic Nodes
Logic nodes control the flow of your workflow. They decide when a workflow starts, which path data takes, how long to wait, and what to do when something goes wrong. There are 33 logic nodes in total.
Starting a Workflow
Trigger
Icon: Zap
Every workflow needs a starting point. The Trigger node fires when a specific event happens in your system — a new booking is created, a payment is received, or a customer signs up.
Inputs: None (this is a starting node)
Outputs: data-out (the event data)
Config:
- Event type: Which event starts this workflow (e.g., booking.created, payment.received)
- Filters: Optional conditions to narrow which events trigger the workflow
Example: Start a workflow whenever a new customer is created, then send them a welcome email.
Scheduled Trigger
Icon: Clock
Run a workflow automatically on a schedule — every hour, every morning at 9 AM, or on the first of every month.
Inputs: None (this is a starting node)
Outputs: data-out (timestamp and schedule info)
Config:
- Schedule type: Cron expression, interval, or specific date
- Timezone: Which timezone to use for scheduling
- Start/end dates: Optional date range for the schedule
Example: Every Monday at 8 AM, pull all bookings for the week and send a summary to the team.
Chat Trigger
Icon: MessageCircle
Entry point for chatbot workflows. Fires when a user sends a message through any connected chat channel.
Inputs: None (this is a starting node)
Outputs: data-out (message text, sender info, channel)
Config:
- Channels: Which channels to listen on (web widget, SMS, etc.)
- Greeting message: Optional auto-reply when conversation starts
Example: When a customer sends a message on your website chat, route it to the Chat Router to determine intent.
Branching and Routing
Condition
Icon: GitBranch
The if/else of workflows. Check whether a condition is true or false, and send data down different paths accordingly.
Inputs: data-in (data to evaluate)
Outputs: true (condition passed), false (condition failed)
Config:
- Expression: The condition to evaluate (e.g.,
amount > 100,status == "active") - Field: Which data field to check
Example: If a booking total is over $500, send it to the manager for approval. Otherwise, auto-confirm it.
Switch
Icon: Route
Like a multi-way Condition. Route data to different paths based on the value of a specific field.
Inputs: data-in (data to evaluate)
Outputs: One output per case, plus a default output
Config:
- Field: Which field to match against
- Cases: A list of values and their corresponding output paths
- Default: What happens if no case matches
Example: Route a support ticket based on its category — "billing" goes to the finance team, "technical" goes to engineering, everything else goes to general support.
Audience Split
Icon: Users
Route data differently based on account type. Each audience (customer, staff, contractor, admin) can follow a different path.
Inputs: data-in (data with account type info)
Outputs: One output per audience type
Config:
- Audiences: Which account types to create paths for
- Transform rules: Optional per-audience data transformations
Example: Send different notification content to customers vs. staff when a booking is updated.
Chat Router
Icon: Route
Route chat messages by intent. Can match keywords, regular expressions, or use AI classification to determine what the user wants.
Inputs: data-in (chat message)
Outputs: One output per route, plus a fallback
Config:
- Routes: Keyword matches, regex patterns, or AI-detected intents
- Fallback: Where to send unmatched messages
Example: If a customer says "cancel," route to the cancellation flow. If they say "status," route to booking lookup. Otherwise, route to the AI assistant.
Synchronization and Merging
Split
Icon: GitFork
Fan data out to multiple branches that all run at the same time. Each branch gets a copy of the same input.
Inputs: data-in (data to distribute)
Outputs: Multiple named outputs
Config:
- Branch count: How many parallel paths to create
- Branch names: Labels for each output
Example: When an order is placed, simultaneously update inventory, charge the payment, and send the confirmation email.
Merge
Icon: Merge
Combine data from multiple branches back into a single stream.
Inputs: Multiple inputs from upstream branches
Outputs: data-out (merged result)
Config:
- Strategy: How to combine data — concatenate arrays, merge objects, or take the first non-null value
Example: After Split sends data to three services, Merge collects all the results into one combined object.
Parallel
Icon: GitFork
Fork execution into independent branches. Unlike Split, each branch runs completely independently with its own copy of the input data.
Inputs: data-in (data to fork)
Outputs: Multiple parallel outputs
Example: Process the same customer record through three different AI analyses at the same time.
Join
Icon: Merge
Wait for parallel branches to finish before continuing. You can wait for all branches, any branch, or race to see which finishes first.
Inputs: Multiple inputs from parallel branches
Outputs: data-out (combined results)
Config:
- Mode: Wait for all, any, or race (first to finish)
Example: Wait for all three parallel AI analyses to complete before combining their results.
Converge
Icon: GitMerge
A rejoin point that waits for multiple branches — including branches that were skipped — and merges their data. More flexible than Join because it handles skipped branches gracefully.
Inputs: Multiple inputs from upstream branches
Outputs: data-out (merged data from all branches)
Example: After a Condition splits into true/false paths, Converge brings both paths back together regardless of which one ran.
Loops and Iteration
Loop
Icon: Repeat
Iterate over an array of items. The connected downstream nodes run once for each item in the array, with an optional transform applied per item.
Inputs: data-in (array to iterate over)
Outputs: item-out (current item), complete (when loop finishes)
Config:
- Array field: Which field contains the array to loop over
- Transform: Optional expression to transform each item
Example: Loop through a list of overdue invoices and send a reminder email for each one.
For Each
Icon: ListOrdered
Similar to Loop, but emits each array item individually with its index. Good for when you need to know the position of each item.
Inputs: data-in (array to iterate)
Outputs: item (current item with index), done (when iteration completes)
Config:
- Array field: Which field contains the array
- Emit index: Whether to include the item index
Example: For each line item in an invoice, calculate tax and emit the updated item.
Timing and Delays
Delay
Icon: Timer
Pause the workflow for a specified amount of time before continuing.
Inputs: data-in (data passes through after delay)
Outputs: data-out (same data, after the delay)
Config:
- Duration: How long to wait (seconds, minutes, hours, or days)
- Dynamic: Option to read the delay duration from a data field
Example: After sending a quote email, wait 3 days before sending a follow-up.
Wait
Icon: Hourglass
Pause the workflow until a specific condition is met or a timeout is reached. Unlike Delay, Wait watches for an external event rather than just counting time.
Inputs: data-in (data to hold)
Outputs: data-out (resumes when condition met), timeout (if condition never met)
Config:
- Condition: What to wait for (e.g., payment received, approval given)
- Timeout: Maximum time to wait before giving up
- Timeout action: What to do if the wait times out
Example: After sending an invoice, wait up to 30 days for payment. If no payment arrives, send to collections.
Approval and Human Input
Request Approval
Icon: UserCheck
Pause the workflow and wait for a human to approve or reject. The approver gets a notification with context about what they are approving.
Inputs: data-in (context for the approval request)
Outputs: approved (approval given), rejected (approval denied)
Config:
- Approver: Who should receive the approval request (user, role, or email)
- Message: Context to show the approver
- Timeout: How long to wait for a response
Example: When a refund request exceeds $200, pause and wait for a manager to approve before processing.
Human Handoff
Icon: Headphones
Transfer a chatbot conversation to a live human agent. The bot stops responding and a human takes over.
Inputs: data-in (conversation context)
Outputs: data-out (after handoff is complete)
Config:
- Department: Which team should handle the conversation
- Priority: Urgency level (low, normal, high, urgent)
- Context message: Summary for the human agent
Example: When the chatbot detects frustration or cannot answer a question, hand off to a live support agent.
Job Assignment and Geography
Assignment
Icon: UserCheck
Automatically assign a job to the best available worker based on configurable rules like proximity, skill match, availability, and tier rating.
Inputs: data-in (job details)
Outputs: assigned (worker found), unassigned (no match)
Config:
- Rules: Assignment criteria (proximity, skills, availability, tier)
- Fallback: What to do if no worker matches
Example: When a new lawn care booking comes in, auto-assign it to the nearest available contractor with a matching skill set.
Geofence
Icon: MapPin
Check if a location falls within a geographic boundary. Route data differently based on whether the location is inside or outside a zone.
Inputs: data-in (data with location coordinates or address)
Outputs: inside (within zone), outside (outside zone)
Config:
- Zone: Which zone or service area to check against
- Location field: Which data field contains the address or coordinates
Example: When a booking request comes in, check if the address is within your service area. If not, send a "sorry, we don't serve your area" response.
Logic Gates
AND Gate
Icon: CircleDot
Boolean AND operation. All inputs must be truthy for data to pass through to the True output. If any input is falsy, data goes to the False output.
Inputs: Multiple inputs
Outputs: true (all truthy), false (any falsy)
Example: Only proceed if the customer has a valid payment method AND an active subscription AND is within the service area.
OR Gate
Icon: CircleDashed
Boolean OR operation. If any input is truthy, data passes through to the True output. Data only goes to False if all inputs are falsy.
Inputs: Multiple inputs
Outputs: true (any truthy), false (all falsy)
Example: Send a notification if either the booking time changed OR the price changed OR the service provider changed.
NOT
Icon: Ban
Boolean inverter. Flips a true value to false and vice versa, then passes the original data through.
Inputs: data-in (value to invert)
Outputs: data-out (original data, with inverted boolean)
Example: Check if a customer is NOT a VIP member, then apply standard pricing.
Validation and Safety
Assert
Icon: ShieldAlert
A guard clause that validates data before the workflow continues. If the assertion fails, data routes to the fail output instead of continuing.
Inputs: data-in (data to validate)
Outputs: pass (validation succeeded), fail (validation failed)
Config:
- Expression: The condition that must be true
- Error message: Message to include when assertion fails
Example: Before processing a payment, assert that the amount is greater than zero and the currency is valid.
Try / Catch
Icon: ShieldAlert
Wrap a section of your workflow in error handling. If anything inside the try block fails, the error is caught and routed to the catch output instead of crashing the workflow.
Inputs: data-in (data to process)
Outputs: success (no errors), error (something failed)
Config:
- Retry: Whether to retry the failed section before catching
- Error types: Which error types to catch (or catch all)
Example: Wrap a Stripe payment call in Try/Catch. If the charge fails, catch the error and send the customer a "payment failed" email instead of crashing.
Retry
Icon: RefreshCw
Automatically retry a failed operation with configurable attempts and backoff timing.
Inputs: data-in (data for the operation to retry)
Outputs: success (eventually succeeded), exhausted (all retries failed)
Config:
- Max attempts: How many times to retry (e.g., 3)
- Backoff: How long to wait between retries (fixed, linear, or exponential)
- Retry on: Which error types trigger a retry
Example: If an API call to Google Calendar fails due to a rate limit, retry up to 3 times with exponential backoff.
Scoping and Context
Scope
Icon: BoxSelect
A container that groups nodes together with shared execution rules. You can add a condition, loop, or error boundary to the entire scope.
Inputs: data-in (data entering the scope)
Outputs: data-out (data leaving the scope)
Config:
- Mode: Condition (run scope only if true), loop (repeat scope), or error boundary (catch errors within)
Example: Wrap a set of notification nodes in a Scope with a condition — only run the entire group if notifications are enabled for this customer.
Data Scope
Icon: Shield
A security gate that controls which fields are visible to downstream nodes. Use allowlists or denylists to filter sensitive data like PII.
Inputs: data-in (full data)
Outputs: data-out (filtered data)
Config:
- Mode: Allowlist (only pass listed fields) or denylist (remove listed fields)
- Fields: Which fields to include or exclude
- PII detection: Automatically detect and remove common PII fields
Example: Before sending customer data to an AI node, use Data Scope to strip out phone numbers and addresses.
Debugging and Logging
Counter
Icon: Hash
A workflow counter that persists across executions. Increment it, decrement it, reset it, or set it to a specific value.
Inputs: data-in (passes through)
Outputs: data-out (data plus current counter value)
Config:
- Operation: Increment, decrement, reset, or set
- Variable name: Name of the counter variable
Example: Count how many times a specific error occurs. If the counter exceeds 10, trigger an alert.
Log
Icon: FileText
Write a message to the workflow execution log. Data passes through unchanged — this node is purely for debugging and monitoring.
Inputs: data-in (data to log)
Outputs: data-out (same data, unchanged)
Config:
- Message template: What to log (supports variable references)
- Level: Info, warning, or error
Example: Log the customer email and booking ID at each step so you can trace workflow execution later.
Workflow Composition
Call Workflow
Icon: Workflow
Execute another canvas as a sub-workflow. Pass data in, wait for it to complete, and receive the result back.
Inputs: data-in (data to pass to the sub-workflow)
Outputs: data-out (result from the sub-workflow), error (if sub-workflow failed)
Config:
- Canvas: Which canvas to run as a sub-workflow
- Input mapping: How to map your data to the sub-workflow's inputs
- Timeout: Maximum execution time
Example: Your "New Customer Onboarding" workflow calls a separate "Welcome Email Sequence" sub-workflow, keeping each workflow focused and reusable.
Termination
Exit
Icon: LogOut
End the workflow and optionally output a final result. Every workflow path should eventually reach an Exit node.
Inputs: data-in (final data)
Outputs: None (this is a terminal node)
Config:
- Status: Success or failure
- Output: What data to return as the workflow result
Example: After all processing is complete, exit with a success status and the final order summary.
Error
Icon: AlertTriangle
Explicitly throw an error with a custom message. This stops the current execution path unless caught by a Try/Catch node.
Inputs: data-in (context data)
Outputs: None (throws an error)
Config:
- Error message: The error message to throw
- Error code: Optional error code for programmatic handling
Example: If a required field is missing after validation, throw an error with a clear message explaining what went wrong.
On this page