Flow Builder: a complete chatbot ready for every channel

Overview

The Complete chatbot: menu, Q&A, CRM deal & tasks template ships an end-to-end, production-ready automated assistant that adapts itself to the channel the conversation runs on:

• On channels with interactive messages (WhatsApp, web chat, Telegram, Messenger, Instagram and API), the menu renders as buttons.
• On text-only channels (email, SMS), the same menu automatically becomes a numbered list — and the contact can reply with the number ("2"), the option text or by tapping the button: every form works.

All the content (messages, buttons and even the understanding keywords) is created in your account's language — English, Portuguese or Spanish.

Prerequisites

• Flow Builder enabled and Admin permission to edit and publish.
• CRM and Tasks enabled to run every path in the template.
• A configured inbox and a team with an eligible agent for human handoff.

Step by step

1. Open Flows → Templates and choose Complete chatbot.
2. Apply it and review the messages, keywords and default CRM pipeline.
3. Check lead_name, lead_email, lead_need, lead_valor and duvida in the data panel.
4. Use Run test with a test conversation and exercise sales, support and handoff.
5. Publish and attach the flow to inboxes only after every output has been validated.

Settings & options

1. Initial menu with three paths: Quotes and sales · Support and questions · Talk to an agent.
2. Sales trail — asks for the name, the email (validated), the need and the budget in mind (numbers only). With the answers it:
   • creates a CRM deal (default pipeline) titled "Opportunity — {name}", with the quoted value and high priority;
   • logs a note on the deal with every mapped answer;
   • opens a task "Send the quote to {name}" due in 1 day;
   • confirms to the contact and hands off to a human.
3. Support trail — asks the question and auto-answers pricing and opening-hours FAQs; anything else becomes a task and goes to an agent.
4. Human agent — option 3 transfers straight away, any time.
5. No valid reply — after 2 guided retries the contact is routed to a human (never stuck).

Use cases

• Lead qualification with a deal, note and follow-up task.
• Support triage with quick answers and escalation for unmatched questions.
• One omnichannel menu for WhatsApp, web chat, email and SMS.

Tips, limits & best practices

• Buttons and numbered lists share the same items: editing the menu once updates the behavior on every channel.
• FAQ answers match keywords in the account language (e.g. "pricing", "cost") — add your own on the condition nodes.
• The quoted value lands on the deal in major units (4900 = $4,900.00).
• Interactive controls depend on the channel's proven capability; always configure the text fallback.

Troubleshooting

• If an action is skipped, inspect the trace and confirm CRM/Tasks are enabled and the target exists.
• If handoff fails, confirm the team belongs to the account and has an eligible inbox member.
• If a reply does not match, review the wait node's input type, options and retry limit.

See also

• Flow Builder: build conversational flows visually
• Flow Builder: trigger data, mapping and transformation
• Flow Builder: action forms

Large HTTP responses and idempotency

In HTTP request, turn off Keep the full response to save only Response mapping fields. The raw body and primary variable are not written to the session or history. Existing flows keep the current enabled default. In this mode, the total read from the API, including pages, is limited to 1 MiB; mapped values total up to 256 KiB. An oversized field is left empty with a warning while small fields are preserved. Node output and session state limits remain active. The request test still shows the response for configuring mappings.

In Idempotency headers, use X-Idempotency-Key or Idempotency-Key with a stable key per operation. Authentication and other headers belong in the vault credential. A key does not guarantee that the external API supports idempotency. A timeout or failure after a paid query does not confirm that no charge occurred: handle the error output without automatically repeating the request.

Extended HTTP timeout per account

The default request timeout remains 15 seconds, with a 30-second ceiling unless configured. An administrator can update flow_builder_http_timeout_seconds through the canonical account update (PATCH /api/v1/accounts/:id), using an integer from 1 to 120; null restores the 30-second ceiling. The node and request tester timeout_seconds respect this ceiling. Node input cannot raise account authority.

Above 30 seconds, the timeout is a total HTTP budget, including pages and response reading. The HTTP step lease covers that budget with a margin. Legacy modes retain their per-page timeout; webhooks are unchanged. A supplier may have charged before a timeout: use the error path to record a note or transfer, without repeating a paid query before reconciliation. Ambiguous results after worker interruption still require manual review.

The synchronous preview also respects the time available to the web request, reserving two seconds to respond. If the requested timeout does not fit, no external request starts and the preview explains why. This does not reduce the node timeout in the worker. The entire paginated sample must fit within that window.