Flows

A flow is a sequence of nodes that starts with a trigger and ends with some useful outcome.

That outcome might be:

• sending data to a vendor
• storing page state for later
• branching based on consent or page context
• loading a script and calling its API
• logging values while you debug

Flow Architecture

Most application flows follow the same pattern:

1. A trigger starts the execution.
2. Data or logic nodes clean up values and decide what path should continue.
3. Action nodes send data, load scripts, or call external systems.

The main node families are:

• Triggers to start the flow
• Data nodes to reshape or persist values
• Logic nodes to branch or stop execution
• Network and coding nodes to call outside systems or page APIs
• Utility nodes to inspect, delay, or document behavior

The Request Lifecycle

When a flow runs, Fluxyn keeps track of a few different pieces of context:

1. The trigger receives the current event payload.
2. $eventData represents that event.
3. $ represents page-level state collected so far.
4. $input changes from node to node as values move downstream.
5. Nodes may update page state, which then becomes part of future executions.

That separation is what makes flows easy to reason about. The current event can change every run, while page state can survive across many runs in the same session.

Good Flow Design

The best flows are usually not the most complex ones. They are the clearest ones.

Good patterns:

• keep one trigger focused on one job
• use Transform or Set Properties early to normalize important values
• branch intentionally with If, Switch, or Filter instead of hiding conditions in many nodes
• keep vendor-specific logic inside official nodes or custom nodes when it starts to repeat
• use Debug while building, then simplify once the flow is proven

Debugging and Release Cycles

Fluxyn gives you two useful ways to validate a flow before you publish:

• Debug sessions in the builder, where you can simulate an event and inspect what each node received and produced
• Live Preview, where the real browser runtime executes against the saved application branch

Live Preview Verification

Use Live Preview when you want to validate the actual runtime behavior on a real page.

Publishing to Production

Production should be the last step, not the place where you discover a selector typo or a missing parameter. Release only after the branch is behaving the way you expect in Live Preview or in the debugger.