How Flows Execute

Understanding how flows execute helps you build more reliable automations.

Execution Flow

1. A trigger fires — Something happens (a chat command, a subscription, a timer tick) that activates a trigger node
2. Forward propagation — The engine walks downstream from the trigger, executing each connected node in order
3. Data flows through edges — Each node receives data from its inputs, processes it, and sends results to its outputs
4. Effects execute — When the engine reaches an effect node, it performs the action (sends a message, switches a scene, etc.)

Key Behaviors

Data Nodes Are Lazy

Data nodes (Text Data, Number Data, Flow Variable, etc.) don't execute until a downstream node actually requests their value. This means unused data nodes don't waste processing time.

Nodes Can Run Multiple Times

If a node is connected to multiple upstream paths, it may execute more than once — once for each path that reaches it. This is by design and allows you to reuse nodes across different branches of your flow.

Effects Have a Then Output

Effect nodes perform an action — send a message, switch a scene, ban a user. Each effect also has a single Then output: a pulse that fires after the effect has run. Wire one effect's Then into another effect's Activate input to run them in a guaranteed order (A.Then → B.Activate means B only runs once A has finished). You can have many effects in a single flow; by default they run left-to-right (see Ordering Multiple Actions).

Check Nodes Branch Execution

Check nodes have two (or more) outputs. Only one output path will execute based on the check's result. For example, an Is Moderator check will either continue down the "true" path or the "false" path, never both.

Ordering Multiple Actions

When a flow fires several effects at once, they run in a defined order:

1. Left-to-right by default. Effects with no explicit ordering run in the order they appear on the canvas — left to right. If you just want one chat message before another, place it further left. (To see the actual order things ran in, run the flow or open a past run — each node shows a numbered badge for the step it ran at.)
2. Then → Activate, for a guaranteed order. Wire one effect's Then output into the next effect's Activate input to force "A finishes, then B runs." Chain as many as you like: A.Then → B.Activate, B.Then → C.Activate. This is a pairwise guarantee — B comes after A — not an exclusive cascade. Effects run breadth-first (level by level): everything the trigger fires directly runs first, then the actions chained off their Then outputs, and so on. So other, unrelated actions can run between the steps of a Then chain. If you need a whole group of actions to finish before anything else runs, use the Sequence node instead.
3. The Sequence node, for ordered groups. The Sequence node runs the whole branch off its first output to completion — including its effects — before starting the next output. This is the "finish this group before the next begins" guarantee that a Then chain does not give. Use it when each ordered step is a small group of nodes rather than a single effect.

Cycle Detection

Flows cannot have circular connections. If Node A connects to Node B, and Node B connects back to Node A, the editor will prevent you from creating that connection. This prevents infinite loops.

Error Handling

If an effect fails — for example, a Twitch or OBS request errors — the failure is logged but the flow keeps going. Later effects still run, and the failed effect's Then output still fires, so one failed action won't silently cancel the rest of your flow. Check the flow's execution log to see which action errored and why.

Structural problems still stop the run: a missing required value, or a circular connection, means the flow can't continue meaningfully.

Execution Environments

Not every node runs in the same place. Flows are executed in one of three environments, and each node in the reference is tagged with a Runs on line that tells you which environment(s) it can execute in.

Backend (Streamerly server)

Most flows run on the Streamerly backend. This environment has full access to:

• The PostgreSQL database (variables, user records, team memberships)
• The Twitch Helix API (sending chat messages, modifying channel state, looking up users)
• The OBS WebSocket bridge (switching scenes, toggling sources and filters)
• Overlay alert sockets (pushing alerts to OBS browser sources)
• Redis (cooldown timing, rate limits)

Any node that performs a visible or persistent action — sending chat, banning a user, switching scenes, triggering an alert — is a Backend node and can only run here.

Frontend (Chatbox Flow Editor)

The Chatbox Flow Editor is a separate flow environment that runs inside the OBS browser source. Instead of reacting to server-side events, it reacts to individual chat messages as they arrive on the client and decides how to render them in the chatbox overlay.

This environment is intentionally sandboxed:

• It cannot talk to the database, Twitch API, or OBS bridge
• It only sees the current ChatMessage object
• Its only terminal effect is Select Variant, which picks a message template variant to render
• All the chatbox-specific check nodes (is-mod, is-sub, is-cheer, has-message-effect, etc.) read directly from the ChatMessage badges, emotes, and flags without any network calls

Because the chatbox is one example of a frontend flow environment, chatbox-only nodes are grouped under the Frontend (Chatbox) runtime class. Future frontend environments may share this runtime class with additional sub-environments.

Shared

A large number of nodes are pure logic — math, string manipulation, list operations, boolean checks, regex, template rendering. These nodes have no external dependencies, so the exact same executor code is registered in both the backend and the chatbox frontend. Shared nodes work identically in any environment and can be used freely in both backend flows and chatbox flows.

How to Tell Which Environment a Node Uses

Every node reference page starts with a blockquote like:

Runs on: Backend — requires the Twitch API to send messages.

Possible values:

• Backend — Server-side only
• Shared — Runs on backend and frontend chatbox
• Frontend (Chatbox) — Chatbox Flow Editor only

The short phrase after the dash explains why the node has that classification (what external dependency it needs, or what data it operates on).

Testing Your Flows

Use these tools to test and debug:

• Manual Trigger — Run your flow on demand without waiting for a real event
• Echo — The Echo effect logs its input to the execution log, letting you inspect data at any point in your flow
• Run button — Click the Run button in the toolbar to execute the flow immediately