Migrating Legacy Bots to Flows

We are retiring three legacy bot types from SendSeven:

• Router — routes incoming messages to other bots or agents via a button menu
• Lead Qualification — asks a sequence of questions and creates a contact
• Appointment — collects info and shares a Calendly link

Their jobs are now done — better — by Flows. This guide explains why, what the cut-over looks like, and how to migrate without disrupting any live conversation.

Nothing breaks today. Existing Router / Lead-Qualification / Appointment bots continue to load, edit, and respond exactly as they always have. You can migrate on your own schedule. The deprecation banner in the bot editor is the only visible change until you decide to convert.

Why we're retiring these bot types

The three legacy bot types each only existed because SendSeven didn't yet have a graph-based workflow engine. Now it does — and Flows can do everything those bots did, plus:

Capability	Legacy bot type	Flows
Multi-channel fallback (WhatsApp → SMS → Email)	No	Yes
Variable substitution in messages	Partial	Yes
Conditional branching on contact properties	No	Yes
Per-language message variants	No	Yes (Phase 5)
Mixing AI Assistants and rule-based logic in one journey	No	Yes (run_assistant node)
Webhook side-effects	No	Yes (webhook node)
Re-running the same logic on incoming_message, tag_added, keyword_match, conversation_opened, manual, api_event, or a schedule	Implicit (incoming only)	Yes — full trigger menu

By moving routing, lead capture, and appointment scheduling into the Flow Builder, you get one consistent canvas to design, test, and observe — instead of three subtly different mini-bot UIs.

What gets converted, and to what

The auto-conversion preserves the logic of the source bot one-to-one. Behaviour you don't see changes; nodes get reshuffled into the Flow shape.

Router bot → Flow

[incoming_message trigger]
        │
        ▼
   [choice node]
   (text + buttons copied verbatim from
    routing_config.messages[0])
        │
   ┌────┼────────────┐
   ▼    ▼            ▼
 [run_  [run_       [open_
 assist] assist]   conversation]
 → Bot A → Bot B   → human inbox

If the source bot had use_llm_fallback=true and intent_keywords configured, an extra branch node is wired in as the choice node's timeout target. Each case:N of that branch routes to a run_assistant node pointing at the matched target bot.

Lead Qualification bot → Flow

[incoming_message]
       │
       ▼
   [send greeting]
       │
       ▼
 [collect_input]   ← one per required_fields entry
       │
       ▼
 [collect_input]
       │
       ▼
   [tag: lead_qualified]
       │
       ▼
 [open_conversation]

Built-in field names (email, phone, first_name, last_name, language, birthday) land on their canonical contact column. Anything else is stored under contact.custom.<name>. Validators (email format, phone format, free-text) are inferred from the field name.

Appointment bot → Flow

[incoming_message]
       │
       ▼
   [send greeting]
       │
       ▼
 [collect_input × N]
       │
       ▼
 [create_tracked_link]   ← only if calendly_event_type_uri was set
       │
       ▼
 [send the booking link]
       │
       ▼
 [open_conversation]

When no Calendly URL is configured on the source bot, the booking-link send node ships with a placeholder body that says "replace this node with your Calendly link" — the flow stays valid and you can edit it before publishing.

How to convert a bot

1. Open the bot in Automation → AI Assistants.
2. You'll see a yellow Deprecated bot type banner at the top of the editor.
3. Click Convert to Flow.
4. You're redirected to the new flow's editor in draft status. The source bot is now inactive but still in your account (so historical conversations and reports still resolve).
5. Test the flow in the Flow Runner with a real contact (see Test a Flow).
6. When you're happy, Publish the flow.
7. Disable any leftover activation rules on the old bot — or just leave them; the bot is already inactive so no traffic hits it.

How the auto-conversion preserves data

Source-bot state	Post-conversion state
The original bot	Preserved — it's only switched to inactive.
Historical conversations and interaction logs	Untouched. Reports continue to attribute past conversations to the original bot.
Activation rules	Preserved but idle (the bot is inactive). Delete or re-target them manually after you publish the flow.
The bot's routing menu (message text + buttons)	Used as the source for the new choice node's prompt + options.
The bot's required fields	Used to generate one collect_input node per field.
The bot's Calendly URL	Used as the create_tracked_link URL in appointment flows.
Conversations that were mid-session with the old bot	Continue against the old bot until they end naturally. New incoming messages go through the new flow once it's published.

Nothing is deleted. If you change your mind, the conversion is fully reversible from the dashboard (see "Reversing a conversion" below).

Testing the new flow before disabling the old bot

When you convert a bot, the source bot is switched to inactive immediately and the new flow starts in draft, so there's a brief window where neither the bot nor the flow is reachable.

The safest test sequence is:

1. Click Convert to Flow. The bot deactivates and a draft flow appears.
2. In the flow editor, click Run as test contact (Flow Builder → top right) and walk through every branch.
3. If the flow misbehaves, leave it in draft and re-activate the original bot from its editor while you iterate on the flow.
4. When the flow is correct, Publish it. Within seconds the new flow is live and the next incoming message will trigger it.

If you absolutely cannot tolerate any downtime, you can also clone the bot first, convert the clone, validate against the clone's traffic, then swap once you're confident.

Reversing a conversion

Any conversion is fully reversible from the dashboard:

1. Re-activate the original bot. Open it in Automation → AI Assistants and switch it back to active.
2. Remove the auto-generated flow. Open the new flow and delete it — or just leave it in draft so it never receives traffic.

No conversation history is lost — your past interaction logs and conversation sessions are never moved.

If you convert the same bot again, the system refuses to create a duplicate flow (it detects the existing one by name) and points you to the flow that already exists.

Manual conversion (for the brave)

Sometimes you don't want a one-to-one mapping — you want to redesign the journey from scratch and use the legacy bot's logic as a reference. That's also fine. Here's how to build each pattern by hand in the Flow Builder.

Replacing a Router bot manually

1. New Flow → trigger incoming_message (any channel, any audience filter).
2. Add a choice node. Title it however you want. Add 2–10 options.
3. Wire each option's outgoing edge to a run_assistant node and pick the target AI Assistant.
4. Optional: add a branch node fed from the choice node's on_timeout config. Use case-rules like last_inbound_message contains_any ["pricing","buy"] and route each case to the right run_assistant.

Replacing a Lead-Qualification bot manually

1. New Flow → trigger incoming_message.
2. send node with your greeting message.
3. One collect_input node per field. Set target_field to contact.email, contact.phone, contact.custom.<name> etc. Pick a validator.
4. tag node that adds lead_qualified (or whatever your CRM expects).
5. open_conversation node so a human can follow up.

Replacing an Appointment bot manually

1. Same as lead qualification up to the field-collection step.
2. Add a create_tracked_link node with your Calendly URL. Set output_var_name to something like booking_link.
3. Add a send node whose body references {{vars.booking_link}}.
4. Finish with an open_conversation node so an agent can confirm the booking.

When this becomes mandatory

The legacy bot types stay in the codebase indefinitely — they will keep running long after the UI hides them. We do not have a sunset date pencilled in.

What changes over time:

1. Today. Deprecation banner in the bot editor. New bots cannot be created with these types via the dashboard (the API still accepts them).
2. Soon. New features (multi-language messages, advanced analytics, webhook nodes inside routing) ship on Flows only. Legacy bots get bug fixes only.
3. Eventually. The bot-type values are removed from the API enum. By that point this guide will give you 60+ days notice and the auto-conversion script will keep working.

For now: convert when it's convenient. There's no rush.

Common questions

Q: Will the converted flow look identical to the source bot to my customers? A: For Router and Lead-Qualification, yes — the message text is copied verbatim and the channel order is the same. For Appointment, the booking link is now a tracked link (so you get click telemetry) — the URL ultimately resolves to the same Calendly page.

Q: Can I edit the generated flow's nodes before publishing? A: Yes. The flow lands in draft status with no live traffic. Rename it, rewrite messages, change the channel chain, anything you like.

Q: What happens to in-flight conversations with the old bot? A: They continue to completion against the old bot. The flow only handles new incoming messages once it's published.

Q: Can I migrate part-way — e.g. convert one Router bot but leave another alone? A: Yes. Each conversion is independent. The CLI supports --bot-id for one-at-a-time, or --all for every bot of that type.

Q: I converted a bot but the flow doesn't fire. A: Most likely the flow is still in draft. Open the flow editor → top-right → Publish.

Related guides

• Build an AI Assistant
• Build a Keyword Bot
• Flow Builder overview
• Prompt engineering