Testing flows: Preview mode, health checks and Flow Logs

Updated 2026-10-23 · 4 min read · By the Convo360 team

Why testing a chatbot is different from testing a website

A website form either works or it does not; a conversational flow has dozens of possible paths depending on what the customer types. A menu that looks complete on the canvas can still have a branch nobody walked through, an AI Reply step with the wrong knowledge base attached, or a Condition block missing a default branch. Testing means walking every realistic path before real customers do, including the paths you hope nobody takes, like an empty reply, an emoji-only reply, or someone typing in a different language than the one you designed for.

Using Preview / Try-it

Convo360's Preview / Try-it runs your flow as a dry run inside the builder itself. You type replies as if you were the customer and watch the flow respond in real time, including AI Reply answers drawn from the actual knowledge base. This lets you test a flow before it is published, and re-test a draft after every edit.

Some steps behave differently in Preview: an actual Send SMS or Send Email may be simulated rather than truly sent, and payment links are shown without creating a real Razorpay transaction. This keeps testing free of side effects while still validating the logic. Webhook and Google Sheets steps do call the real connected service in Preview, so use a staging sheet or sandbox endpoint if you do not want test data mixed with production data.

Running a health check

Before publishing, run the flow's health check. It scans the whole canvas for structural problems: blocks with no outgoing connection (dead ends), Condition blocks missing a default branch, or a Go To block pointing at a step that was deleted. Fixing these before publishing avoids customers getting stuck mid-conversation with no way forward. A flow that passes the health check is not automatically correct, it only confirms there are no structural gaps; you still need Preview to confirm the logic itself does what you intend.

A practical test plan before every publish

Rather than testing randomly, work through a short checklist of realistic and edge-case inputs. For a typical guided sales or support flow this covers most of what goes wrong in production:

Reading Flow Logs after you go live

Once a flow is live, Flow Logs record every conversation step by step, including a note on anything that failed: an SMS blocked by DLT mismatch, a webhook that timed out, or an AI Reply that could not find an answer. Reviewing logs in the first few days after publishing, and periodically after that, is the fastest way to catch problems real customers hit that Preview did not simulate, like a slow third-party API or an unexpected reply format.

Beyond failures, Flow Logs are also useful for spotting patterns: if a large share of contacts are landing on your AI fallback rather than your intended menu options, that is a sign to add a proper button or List Menu entry for whatever they are asking, rather than leaving it to the fallback permanently.

Versioning and rollback

Every published flow keeps its draft and published versions separate. You can edit and test a draft freely without affecting the live flow customers are talking to. If a new published version causes problems, roll back to the previous published version in a couple of clicks, restoring the last known-good behaviour while you fix the draft. This matters most during high-traffic periods, a festive broadcast or a marketing push, when you want the freedom to fix a small issue without risking the whole campaign.

A simple pre-launch checklist

1. Walk every branch in Preview, including edge cases like an empty reply or an unexpected word.
2. Run the health check and resolve every flagged dead end.
3. Confirm any Send SMS, Send Email or Razorpay payment link block points at the correct, tested template.
4. Publish, then watch Flow Logs closely for the first day.
5. Keep the previous published version noted so you can roll back quickly if needed.

It helps to have someone other than the flow's builder walk through Preview before launch, ideally someone unfamiliar with the intended logic. A builder tends to type the replies the flow expects; a colleague or team member typing naturally is more likely to stumble on the same odd phrasing a real customer would use. For flows shared across a team with different roles, this review step is a good habit to add to your publishing routine rather than something done only for the first version of a flow.

Step by step

1. Open Preview / Try-itLaunch dry-run mode from within Flow Builder before publishing any changes.
2. Walk every branch manuallyType realistic and edge-case replies to confirm each Condition branch and menu option behaves correctly.
3. Run the health checkScan for dead ends, missing default branches and broken Go To links.
4. Fix flagged issuesResolve every warning before publishing the flow live.
5. Publish and monitor Flow LogsWatch per-step notes for the first day to catch anything Preview could not simulate.
6. Roll back if neededRevert to the previous published version instantly if the new one misbehaves.

Example conversation

Frequently asked questions

Related reading

Available across India — see WhatsApp & AI calling automation by state and city.