Logic Nodes
Logic nodes let you route visitors using a reusable logic script.
They are for cases where normal conditions become too awkward, repetitive, or hard to manage on the funnel canvas.
What logic nodes are for
Use logic nodes when you want routing to depend on multiple pieces of visitor context at once.
For example, you might want to route based on:
- country, region, city, or continent
- device type, OS, browser, or language
- ISP or connection type
- current URL, referrer, or tracking domain
- tracking fields captured from the incoming URL
- visitor tags
- form/action data submitted earlier in the funnel
- local time or day logic
You could build some of this with condition nodes, but it can become messy when the logic has many branches.
A logic node keeps the funnel cleaner by moving the decision into a named script, then routing by the result that script returns.
Logic scripts vs logic nodes
Logic scripts are reusable assets.
They contain the routing logic itself -- for example, "return us_mobile when the visitor is in the US on mobile, otherwise return default".
Logic nodes are where those scripts are used inside a funnel.
The logic node runs the selected script for the current visitor. The script returns a route key, and the outgoing connection matching that route key is used.
In plain English:
- visitor reaches the logic node
- FunnelFlux runs the selected logic script
- the script returns a route key
- the logic node follows the matching outgoing connection
Route keys
Route keys are the labels your script returns.
For example, a script might return:
ustier_onemobilebusiness_hoursdefault
Those route keys then need to exist on the outgoing connections from the logic node.
Always include a default route. This is your safety path if the script cannot run, returns something unexpected, or does not match anything else.
Do not send default somewhere random. Send it to a path that is safe for normal traffic, such as a general lander, fallback offer, or catch-all route.
Simple example
A very simple country-tier script might look like this:
if country == "US" {
return "us"
}
if oneOf(country, "CA", "AU", "NZ") {
return "tier_one"
}
return "default"
The logic node would then have outgoing routes for us, tier_one, and default.
This is intentionally simple. In practice, logic nodes become more useful when you combine several checks into one clearer decision, rather than making a large condition-tree on the canvas.
When to use logic nodes
Use a logic node when:
- a condition node would need too many branches
- you want the same routing logic reused in multiple funnels
- you want to make decisions from tracking fields, tags, time, device, geography, or form data together
- the routing rule is easier to describe in code than by drawing many visual branches
- you want AI to help generate or maintain routing logic from a plain-language brief
For example, you might use one logic node to route:
- mobile US visitors during business hours to one path
- desktop visitors to another path
- traffic from specific ISPs to a filtered path
- visitors with a prior tag to a different offer sequence
- submitted form answers to different follow-up paths
When not to use logic nodes
Do not use a logic node just because it exists.
If your rule is simple, use a condition node. A condition node is easier to inspect visually and is often better for basic "if this, then that" routing.
Do not use logic nodes when:
- you only need a simple country/device/browser condition
- the routing should be obvious to someone glancing at the funnel canvas
- you are not comfortable maintaining the script
- you need an external system to make a live decision before routing
For external live decisions, a future middleware-style flow is the better conceptual fit. Logic nodes are for FunnelFlux-side routing logic using the context available at runtime.
Using AI to write logic scripts
Logic scripts are a good fit for AI-assisted writing.
You can describe the routing goal in plain language, then ask AI to return:
- a short description of what the script does
- the logic script code
- the route keys you need to connect in the funnel
The API documentation includes a detailed AI prompt and reference block you can use for this.
Logic Scripts API documentation
You should still review the result before using it. The route keys returned by the script must match the outgoing routes you wire from the node.
Testing logic nodes
Test logic nodes the same way you test other routing behavior: run through the funnel yourself and confirm the expected path is used.
When testing, check:
- the route keys returned by the script
- whether every returned route key has an outgoing connection
- whether
defaultis connected to a safe path - whether your test visitor actually has the context you expect, such as tags, tracking fields, or submitted form data
If you are testing geography, device, ISP, or language rules, remember that your own browser and network may not match the visitor context you are trying to test.
Common mistakes
Do not forget the default route. It is the fallback for errors, missing routes, and unexpected script results.
Do not return route keys that you never connect from the logic node.
Do not make route keys vague, such as a, b, or path1. Use names that explain the route, such as us_mobile, business_hours, or filtered_isp.
Do not build huge scripts when a normal condition node would be clearer.
Do not rely on untested assumptions about visitor context. If your script depends on a tracking field, tag, or form value, make sure that value is actually present before the visitor reaches the logic node.
Technical reference
This article is focused on how to use logic nodes conceptually.
For the full script language, available variables, helper functions, route-key rules, validation endpoints, and API workflow, use the technical documentation:
Logic Scripts API documentation
Updated on: 09/06/2026
Thank you!
