ConnectWiz Flows

Automation that knows who it’s talking to.

Generic workflow tools automate data rows. Flows automate conversations — where the unit of work is a person waiting for an answer, a "wait 3 days" step is normal, and the permission question sits on the canvas as a real node. 27 node types, every channel, honestly bounded.

Runs on every inbound channel Consent guards on the canvas Real dry-runs, per-step traces
Flow — appointment reminder, live
Trigger · Mondays 09:00
Consent guard
Send reminder
Skip politely
Slot booked — every step traced
27
Node types — and each one ships with its runner, editor form, validator rules, tests and docs on the same day
6
Trigger kinds — new conversation, keyword, schedule, form submission, agent button, secured webhook
~97
Distinct validator checks before a flow publishes — broken flows fail in the editor, not on a customer
Days
How long one run can live — waits are durable, so "remind them in 3 days" is a step, not a hack

Triggers

Six ways a flow starts — each one a first-class card on the canvas

New conversation

Greet every first contact with a structured welcome — on the widget it can even fire when the chat window opens, before the visitor types.

Keyword

A customer message matching your keywords starts the right flow — "appointment", "price", "return" — on any channel.

Schedule

The clock picks an audience and opens conversations — renewal reminders, seasonal check-ins — with consent guards standing between the schedule and the send.

Form submitted

A form submission starts a flow with every answer available as variables — the follow-up begins the second the form lands.

Agent button

Agents launch a flow on a live conversation with one click — the refund procedure, the onboarding sequence — human judgment choosing automated execution.

Webhook, secured

Every webhook trigger gets its own public URL with its own secret, HMAC verification over the raw body and replay protection. A payload is data, never instructions: it can name a person, but it can never steer the flow’s internals.

The node catalogue

27 node types — and a rule that keeps them honest

A node enters the palette only on the day its runner, editor form, validation, tests and documentation all exist. The palette is generated from the engine itself — the editor cannot offer a step the runner won’t run.

Abstract 3D illustration: a node graph of glass tiles connected by glowing curves with one active emerald path ending in a chat bubble

Messaging (6)

Message, choices, media, WhatsApp template, in-chat form, and the channel-rich sender — the words and surfaces your customer actually sees.

Logic & timing (5)

Condition, switch, connector (jump to a step or call a sub-flow, depth-limited), durable delay, and business hours — branching that respects clocks and calendars.

Data (4)

Capture answers, set variables, call any REST API, and read or write your own data tables — the integration that needs no integration.

AI (4)

Classify intent, answer from your knowledge base, or hand a step to a tool-using AI agent that can look things up — including your CRM — before it speaks.

Human & routing (1)

One multi-action node assigns departments and agents, applies tags, sets priority, opens or closes the conversation — the handover from automation to humans, explicit.

CRM & sales (3)

Your CRM as an app in the palette: 10 read and 7 write operations — each write behind three gates (connected, capable, and explicitly opened by an admin, all closed by default).

Commerce, calls & booking (2)

Look up the catalog, place an order, trigger a call, offer and book real appointment slots — deliberately two verbs, offer then book, so the customer chooses.

Guards (2)

Consent and frequency as visible steps — the permission question on the canvas, where reviewers can see it, not buried in settings.

Channel-aware sending

One flow, every channel — rich where rich exists

The rich sender carries about twenty channel-specific actions — lists, reply buttons, carousels, product cards, receipts, coupons, location requests, call buttons, WhatsApp Flows — and asks the channel three separate times what it can render: in the palette, at save, and at send. Because the answer changes.

Rich elements per channel

A list on WhatsApp, buttons on Telegram, a carousel on Messenger — composed once, validated against what each connected channel actually supports before it can ship.

WhatsApp Flows inside

Meta’s native in-chat form screens send as a flow step, with a hosted encrypted data endpoint feeding live screen data — and when a data source hiccups, the screen still renders with a polite notice instead of dying.

Templates that teach

Eight built-in flow templates — triage, FAQ, order status, lead capture, follow-up, menu, appointments, awaiting — each one demonstrating a pattern, deliberately few instead of five hundred near-duplicates.

Testing & versions

"It worked in the editor" finally means something

Abstract 3D illustration: a glass timeline of process steps lighting in sequence, one paused with an hourglass, a lens inspecting another step

Real dry-runs

The test button runs the actual engine with a collecting output instead of a sending one — the same runner, the same trace, zero messages sent. What you watch is what production does.

Versions & restore

Publishing snapshots a version; any version restores with one click. Friday’s experiment never holds Monday hostage.

A validator that argues

Roughly 97 distinct findings — dead branches, missing captures, channel mismatches — surfaced in the editor before publish, because a customer is the wrong place to discover a typo.

Runs, traced & funneled

Every run records each step’s input and output; a funnel view shows where people flow and where they drop. Debugging is reading, not guessing.

Guards

The permission question, drawn on the canvas

Consent as a step

The consent node checks the dimensioned consent ledger — channel, purpose, category — before a branch that markets. Reviewers see the guard in the diagram, auditors see it in the run trace.

Frequency as a step

The frequency node caps how often a person can be touched by automation — list fatigue prevented structurally, not by hoping campaigns coordinate.

Clocks respected

Durable delays and the business-hours node mean a flow can wait three days and still land in working hours — patience as a feature of the engine, not a cron job taped on.

The honest fine print

What Flows refuses to be — with the reasons

No parallel branches

A person is not in two conversation branches at once. Splitting a human into concurrent paths is a data-pipeline idea that produces double messages — refused by design.

No per-item loops

"For each product, send a message" is a spam pattern. Where iteration is legitimate, a single node renders it as one list or carousel message.

No code node

Arbitrary code inside a customer conversation engine is a security and support liability we chose not to sell. The REST node calls your systems; your code stays in your systems.

Bounded on purpose

32 nodes per pass, sub-flow depth of five, sized variable space — generous for conversation design, hostile to runaway automation. The ceilings are documented, not discovered.

Flows FAQ

Before you build

More in the full FAQ, or ask us directly.

Generic workflow tools automate data rows in seconds-long executions. A ConnectWiz flow’s unit of work is a person waiting for an answer: runs pause on questions, survive multi-day waits, remember the conversation, and carry consent and frequency guards as first-class steps. It’s automation shaped like a conversation, because that’s what it runs inside.

Every inbound channel — a flow started by a keyword, a button tap or a new conversation behaves the same whether the customer is on WhatsApp, Telegram, Messenger, Instagram, the web widget or SMS. Rich elements adapt per channel: the palette, the save-time validator and the send-time handler all ask the channel what it can actually render.

Yes — with a real dry-run, not a simulation: the test runs the actual flow engine with a collecting output instead of a sending one, so what you watch in the test is exactly what production will do. Add versioning with one-click restore and a validator with roughly 97 distinct checks, and "it worked in the editor" finally means something.

Flows handle the conversational side — including scheduled flows that open threads for an audience — while broadcasts have their own engine with warm-up ladders and restraint rules. Both share the same consent architecture, and the consent and frequency guards are visible steps on the flow canvas itself.

On purpose. A person can’t be in two conversation branches at once, and a per-item repeat step is how automation becomes spam. Where iteration is legitimate — a list message, a carousel — the node renders it as one message. These are design refusals, documented, not missing features.

Draw the conversation. The engine keeps its promises.

Start from a template, dry-run it against the real engine, publish with a version you can always walk back.