Automations: a visual canvas that runs your funnel
Mass automations are built on a visual, node-based canvas: you drag triggers, actions, conditions, and delays onto a flow, connect them, and the execution engine runs that flow in the background when a real event fires. An AI co-builder can generate or modify an entire workflow from a plain-English description, and pixel, form, and CRM events fan out to any automation listening for them. This guide explains the node types, the canvas, the AI builder, and how a run executes.
18 min read · The complete automations guide
The node-based canvas
A workflow is a graph of nodes and edges you assemble visually.
Automations are authored on a React Flow canvas: each step is a node, and edges connect them top to bottom. Every workflow starts with exactly one trigger node and flows into actions, conditions, and delays. The whole graph — nodes, edges, and viewport — is saved as structured flow data on the workflow record, alongside its trigger type, trigger config, and execution settings (model, temperature, retries, timeout).
The canvas comes with the usual flow affordances — a minimap, pan and zoom controls, and a background grid — and a palette of node components grouped by what they do. Because the graph is data, the same workflow can be rendered, edited, executed, and generated by AI without changing its representation.
- Nodes + edges — every step is a node; edges wire them top-to-bottom into a flow.
- One trigger to start — each workflow begins with a single trigger node, then branches into actions and logic.
- Saved as flow data — nodes, edges, viewport, trigger type/config, and settings persist on the workflow record.
- Full canvas UX — minimap, controls, background grid, and a categorized node palette.
Three automation types
The same canvas powers event automations, build workflows, and admin sequences.
Workflows declare an automation type that frames what they're for. Funnel automations are event-driven — they fire on user actions like a form submit, a page visit, a purchase, or a quiz completion. Workflows are build-agent flows that generate funnels, copy, and content (for example: onboarding data → wireframe → copy prompts → AI copy). Admin automations are backend flows like nurture campaigns and internal notifications.
The type informs which nodes make sense and how the flow runs, but they share one canvas and one execution model, so you learn the builder once and apply it across event marketing, content generation, and backend operations.
- funnel_automation — event-driven flows triggered by user actions (form submit, page visit, purchase, quiz complete).
- workflow — build-agent flows that generate funnels, copy, and content from inputs.
- admin — backend flows — nurture sequences, internal notifications, and operations.
- One builder — all three share the canvas and execution engine, so the skill transfers.
Triggers: what starts a flow
A rich set of triggers, including first-party pixel and CRM events.
Every flow begins with a trigger. The core trigger types include form submitted, page visited, quiz completed, button clicked, exit intent, time-based, purchase, tag added, and contact created. On top of those, dedicated CRM triggers (contact created, deal stage changed, lifecycle changed) and pixel triggers (page view, form submit, identify, purchase, lead-score threshold) let automations react to the platform's own first-party data.
This is what makes automations feel native rather than bolted-on: because the tracking pixel and CRM emit structured events, an automation can listen for "lead score crossed a threshold" or "deal moved to a stage" directly, without a third-party integration in the middle.
- Core triggers — form_submit, page_visit, quiz_complete, button_click, exit_intent, time_based, purchase, tag_added, contact_created.
- CRM triggers — contact created, deal stage changed, and lifecycle changed react to pipeline movement.
- Pixel triggers — page view, form submit, identify, purchase, and lead-score threshold react to first-party tracking.
- Native by design — automations listen directly to the platform's own events — no middleman integration required.
Actions, logic, data & AI nodes
Everything from sending an email to branching on a condition to calling a model.
Downstream of the trigger, nodes do the work. Communication nodes send email, SMS, WhatsApp, or Slack messages. Logic nodes shape the path: a condition node branches on a field with an operator and value (its true/false handles wire to different downstream nodes), and a delay node waits a set amount of time. Data nodes add or remove a tag, update the CRM, or call a webhook. AI nodes hand a task to a model (OpenAI or Claude) inside the flow.
For build-style workflows there's a second family: funnel-generation nodes like onboarding data, wireframe generator, copy-prompt generator, AI copy generator, and render design, plus integration nodes for Google Sheets, Airtable, and Calendly. You compose these into a flow that, end to end, can take a real-world event and produce a real-world outcome.
- Communication — email, SMS, WhatsApp, and Slack message nodes.
- Logic — condition (branch on field/operator/value via true/false handles) and delay (wait) nodes.
- Data — tag (add/remove), CRM (operation + fields), and webhook (method + URL) nodes.
- AI — OpenAI and Claude nodes run a described task inside the flow.
- Build & integrations — funnel-generation nodes plus Google Sheets, Airtable, and Calendly integrations.
The AI co-builder
Describe the automation; AI lays out the nodes and edges.
You don't have to place every node by hand. An AI co-builder turns a plain-English description into a complete workflow — it picks the automation type, emits valid nodes with the right per-type config, wires the edges (including the true/false branches off condition nodes), and lays the graph out top-to-bottom with sensible spacing. A separate modify path lets AI edit an existing workflow rather than only generating from scratch.
The generator is constrained to the real node vocabulary — the same trigger, communication, logic, data, and AI node types the canvas supports — so what it produces is immediately runnable and editable. Pre-built templates cover common funnels (for example a welcome-email sequence that fires on form submit), giving you a vetted starting point you can then refine by hand or with the AI.
- Description → workflow — AI chooses the type, emits valid nodes and config, wires edges, and lays out the graph.
- Generate or modify — one path builds from scratch; another edits an existing workflow in place.
- Constrained to real nodes — output uses the canvas's actual node vocabulary, so it's runnable immediately.
- Templates — vetted templates for common funnels seed a flow you can refine.
How a run executes
Runs happen in the background, node by node, with a dry-run mode.
When a workflow runs, an execution engine walks the graph node by node from the trigger, persisting state so a long flow can advance across requests. Execution kicks off in the background using an admin client, so it survives past the response that started it, and each run is tracked as an execution record you can inspect. A dry-run flag propagates through the run so nodes that cause external side-effects can be gated while you test.
Plan limits govern how many automations a tenant can run, consistent with the rest of the platform's tiered limits. Combined with the background engine, this lets a workflow do real work — send a message, update a deal, call a model — reliably and within the account's entitlements.
- Node-by-node engine — the engine advances from the trigger through the graph, persisting state between steps.
- Background execution — runs continue past the initiating request via an admin client and are tracked as execution records.
- Dry-run mode — a dryRun flag lets side-effecting nodes be gated while you test a flow.
- Plan-governed — the number of automations a tenant can run follows the platform's tiered limits.
Events fan out to enrolled automations
A pixel hit or CRM change dispatches to every automation listening for it.
Automations are wired into the platform's event stream. When the tracking pixel ingests an event — for example a content view — a dispatcher fans it out to any tenant automations registered for that trigger and starts their runs. The dispatch is fire-and-forget: a crash in an executor never breaks the pixel write that already succeeded, and missing automation tables on legacy installs soft-fail to a no-op so the public pixel route can't error.
The same pattern connects CRM movement to automations. This is the closed loop that ties the suite together: the pixel and CRM produce events, automations consume them, and actions like emails and field updates produce new events in turn — all on the same first-party data graph.
- Pixel → automations — ingested pixel events are matched and dispatched to automations registered for that trigger.
- Fire-and-forget — an executor crash never tanks the pixel write; dispatch failures are isolated.
- Soft-fail safe — legacy installs without the automations table degrade to a no-op instead of 500-ing.
- Closed loop — events drive automations, whose actions create new events — one continuous graph.