Build

Flow Node Automation Playbook (Production Detailed)

Detailed production guide covering cross-channel behavior and advanced automation nodes with config patterns, routing, edge cases, and real deployment examples.

Back to Docs

Audience: Product, implementation, QA, support operations, and platform adminsRead Time: 35 minUpdated: May 2026

Cross-channel baseline requirements (Web, WhatsApp, Telegram)

Run the same logical flow behavior across Web, WhatsApp, and Telegram; avoid channel-specific business logic drift unless policy requires it.
Conversation inactivity auto-close must be configurable (default 10 minutes) and applied to all channels, including web.
Persist inactivity close configuration at bot + channel level so operations can tune independently by traffic profile.
When inactivity timeout is reached, mark conversation closed in runtime state and support queue state to prevent zombie sessions.
If a user replies after auto-close, start a clean new session while preserving prior transcript/audit trail for analytics continuity.
For WhatsApp out-of-session responses, route to approved template-message path; for web/telegram, continue normal message path.
Track auto-close events as analytics events (`conversation_auto_closed`) and audit actions for operational visibility.
Production validation: test close/resume behavior separately for web widget, WhatsApp callback, and Telegram webhook.

Concern Resolution AI output rules

User-facing output must not append static source tags like `Sources: C1` when clean response mode is selected.
Use response template format such as `You can consult {{answer}}` and keep answer value-only for display fields.
Store structured result in key-value form (`label`, `id` or `value`) for downstream buttons/inputs and edge routing.
Support two explicit outcomes from grounded node: `grounded` and `fallback` (or equivalent edge handles).
Fallback response must be configurable per flow, not hardcoded globally.
If answer resolves to object payload, template should map explicit property path (example:
```
{{deptOption.label}}
```
) to avoid raw JSON rendering in chat.
Persist answer payload variables in node-level output vars so they remain inspectable in later builder sessions.
Edge labels and source handles should remain visible and deterministic for maintainability and QA replay.

Node 1 - Scheduler / Reminder

Purpose: schedule delayed follow-up actions after current turn ends or pauses; use for reminders and recovery journeys.
Config keys: scheduleType, runAt, offset, timezone, dedupeKey, payload, maxExecutions, expiryAt, outputVar.
Route outcomes: `scheduled`, `skipped`, `failed`, `expired`.
Expected edge configuration: wire `scheduled` to the later delivery or confirmation step, `skipped` to a safe bypass path, `failed` to retry or manual review, and `expired` to a recovery branch.
Past-time policy required: `skip`, `send_immediately`, or `fail`.
Dedupe strategy: use business key (`flow_id:customer_phone:reminder_type`) to avoid duplicate reminders on restarts.
Support cancel/reschedule when appointment or intent changes.
Store UTC internally; display localized time to user and agent.
Common mistakes: using Scheduler for a short in-turn pause, omitting dedupe protection, or forgetting to handle expired jobs.
Production examples: appointment reminder 24h before visit; payment pending reminder after 30m; no-show follow-up after 2h; lead callback next business day; renewal alert 3 days before expiry.

Node 2 - Database / Record

Purpose: provide no-code persistence layer for create/find/update/upsert/delete/list without forcing external API wiring.
Config keys: action, collection, where, data, uniqueKey, outputVar, optional schema + pagination/sort fields.
Route outcomes: `success`, `not_found`, `duplicate`, `validation_failed`, `failed`.
Expected edge configuration: wire `success` to the next business step, `not_found` to create-or-ask-again handling, `duplicate` to reuse/correction, `validation_failed` to user correction, and `failed` to fallback or manual review.
Upsert pattern: if unique key exists then update else create.
Use `phone` only when one row per person is desired; use `appointmentId` or `bookingId` when the same user can have many appointments.
Schema validation is mandatory per collection for required fields, types, enum constraints, and uniqueness.
Security baseline: tenant isolation, PII encryption at rest, audit trail for mutating operations, soft delete where required.
Handle stale/multiple record matches explicitly; do not silently pick arbitrary rows.
Production examples: save lead capture; fetch customer profile by phone; update payment status; create ticket record; list pending approvals with pagination.

Node 3 - Webhook Trigger

Purpose: receive external events to start/continue flows with authenticity checks and mapping.
Config keys: method, path, authType, secret/bearer/basic creds, verifySignature, idempotencyKeyPath, payloadMapping, outputVar.
Route outcomes: `received`, `duplicate`, `unauthorized`, `invalid_payload`, `failed`.
Stored result status values: `received`, `rejected`, `duplicate`, `failed` in `outputVar.status`.
Expected edge configuration: wire `received` to the normal business path; send `duplicate` to a no-op or dedupe branch; send `unauthorized` to a security or end branch; send `invalid_payload` to a repair or dead-letter path; send `failed` to retry or fallback handling.
Require idempotency key (`event_id + provider + tenant`) to handle provider retries safely.
Reject stale replay payloads using timestamp age window (for example 5 minutes).
Validate required payload fields before routing into business steps.
Support out-of-order event handling via state-transition validation (for example paid cannot move back to failed without refund).
Production examples: Razorpay payment captured; website form submitted; CRM lead updated; Shopify order created; lab report ready callback.

Node 4 - Human Approval

Purpose: pause automation for authorized decision and then resume deterministic branching.
Config keys: approvalTitle, approvalMessage, approvers (user/role), approvalMode, timeout, onTimeout, buttons, outputVar.
Route outcomes: `approved`, `rejected`, `more_info_required`, `timeout`, `failed`.
Stored result status values: `approved`, `rejected`, `timeout`, `escalated`, `more_info_required` in `outputVar.status`.
Expected edge configuration: wire `approved` to the success path, `rejected` to the safe deny path, `more_info_required` to follow-up or requester clarification, `timeout` to escalation or auto-reject handling, and `failed` to a fallback or manual recovery step.
Approval snapshot must be immutable so approver sees exactly what requester submitted at approval time.
Default safety for financial/compliance actions: avoid auto-approve; prefer `auto_reject` or `escalate`.
Late-action policy required: reject or explicitly accept late approvals after flow expiry.
Persist full audit envelope: approver identity, decision timestamp, visible payload snapshot, optional comment.
Production examples: refund approval; manual document verification; urgent appointment exception; custom pricing approval; insurance claim decision.

Node 5 - File Processor / OCR

Purpose: parse uploaded files for OCR, classification, field extraction, validation, and summarization.
Config keys: inputFiles, processingMode, acceptedTypes, maxFileSizeMb, schema, confidenceThreshold, outputVar.
Route outcomes: `success`, `partial`, `low_confidence`, `invalid_file`, `manual_review_required`, `failed`.
Stored result status values: `success`, `partial`, `low_confidence`, `invalid_file`, `failed` in `outputVar.status`; `manual_review_required` is a route for human review, not a stored status.
Expected edge configuration: wire `success` to the normal next step, `partial` and `low_confidence` to review or enrichment, `invalid_file` to re-upload or dead-letter handling, `manual_review_required` to approval/manual review, and `failed` to fallback or support.
Use strict extraction mode for regulated data: return null when uncertain, never hallucinated values.
Implement file hygiene: extension + mime checks, size limits, optional malware scan, encryption, retention policy.
Support multi-page policies (`first page`, `all pages`, selected pages).
Mismatch handling: if detected type differs from expected document type, route to invalid_file.
Production examples: PAN/Aadhaar extraction; invoice amount extraction; prescription parsing; resume extraction; address proof validation.

Node 6 - Unified Notification

Purpose: send multi-channel notifications in one node with strategy-based fallback.
Config keys: recipients, channels, strategy, messageCategory, dedupeKey, outputVar.
Route outcomes: `sent`, `partially_sent`, `failed`.
Strategies: `first_success`, `priority_order`, `send_all` depending on SLA and cost profile.
Validate template variables before send to avoid blank placeholders reaching users.
Respect channel restrictions (WhatsApp session/template, SMS compliance, email validity).
Treat unavailable recipient fields as per-channel skip, not global failure unless all channels fail.
Expected edge configuration: wire all three outcomes (`sent`, `partially_sent`, `failed`) to the right follow-up steps; branch later if you need extra business logic.
Production examples: appointment confirmation; payment receipt; fallback WhatsApp->SMS->Email; customer+admin parallel alerts; reminder chain notifications.

Node 7 - Wait Until / Date-Time Condition

Purpose: resume flow at business-aware target datetime instead of fixed delay-only behavior.
Config keys: targetTime, offset, timezone, businessHours, pastTimePolicy, outputVar.
Route outcomes: `resumed`, `skipped`, `failed`.
Expected edge configuration: wire `resumed` to the next business step, `skipped` to a bypass or alternate path, and `failed` to retry, manual intervention, or fallback handling.
Past-time policy required: `continue_now`, `skip`, or `fail`.
If target falls outside business hours, move to next valid send window.
Persist state before waiting and define behavior for early user replies (`resume_early`, `cancel_wait`, etc.).
Holiday-aware scheduling can be layered on top of this node via calendar service integration.
Production examples: reminder one day before appointment; defer after-hours lead to next morning; pending payment reminder after 30 min; expiry notice in 3 days.

Node 8 - Analytics / Track Event

Purpose: measure conversion, drop-off, escalation, and quality outcomes across flows.
Config keys: eventName, properties, failurePolicy, dedupeKey/throttle controls, outputVar.
Route outcomes: `tracked`, `failed` (or fire-and-continue behavior based on policy).
Event execution should be non-blocking by default for customer journey continuity.
Mask or exclude PII (phone, symptom text, document identifiers) before telemetry export.
Use stable naming taxonomy (example: lead_created, appointment_booked, payment_failed).
Throttle repeated events to avoid noisy funnels.
Expected edge configuration: wire `tracked` to the next business step and `failed` only when analytics must be enforced; do not block the user journey on provider issues by default.
Production examples: track lead captured; track handover created; track AI fallback; track payment failed; track form completion.

Node 9 - Audit Log

Purpose: immutable compliance log for high-risk workflow actions.
Config keys: action, entityType, entityId, metadata, sensitivity, failurePolicy, outputVar.
Typical routes: `logged` and `failed` (depending on failurePolicy behavior).
Use append-only storage model and tenant isolation for forensic reliability.
For consent/payment/approval paths, set failurePolicy to block continuation when audit write fails.
Mask sensitive data in builder previews and operational logs.
Capture actor identity + timestamp + action payload reference on every entry.
Expected edge configuration: wire `logged` to the next step and reserve `failed` for strict-policy branches; do not assume the node is always non-blocking.
Production examples: consent captured; payment status changed; document uploaded; refund approved; AI policy response generated.

Node 10 - Language Detect / Translate

Purpose: detect user language and translate inbound/outbound text for multilingual support.
Config keys: action, inputText, targetLanguage, outputVar, optional confidence/support thresholds.
Route outcomes: `detected`, `low_confidence`, `unsupported`, `failed`.
Expected edge configuration: wire `detected` to the normal branch and use `low_confidence`, `unsupported`, and `failed` for fallback or language-selection steps.
Store preferred language in user/session context and reuse in downstream templates.
Handle mixed-language inputs (Hinglish/Tenglish) with low-confidence route and explicit language confirmation.
Protect domain terms (medical/legal) with review rules for high-risk flows.
Allow mid-flow language switch without losing journey context.
Production examples: detect Telugu for routing; translate complaint to English for extraction; translate reply back to user language; locale-based template selection.

Node 11 - Queue / Assignment

Purpose: assign tickets/leads to teams with workload and skill-aware routing.
Config keys: queueName, assignmentStrategy, priority, skillsRequired, SLA, outputVar.
Route outcomes: `assigned`, `queued`, `failed`.
Expected edge configuration: wire `assigned` to the next human-support step, `queued` to retry or escalation handling, and `failed` to a safe fallback.
Strategies: round-robin, least-busy, skill-based, priority.
Create duplicate-protection key to avoid repeated ticket creation on repeated user messages.
SLA timestamp should be computed at assignment/queue time and exposed for dashboards.
When no agent is available, queue safely and trigger escalation notification path.
Production examples: billing queue assignment; sales lead round robin; language-specific handover; emergency priority queue; location-based support routing.

Node 12 - Dedupe

Purpose: prevent duplicate leads, tickets, appointments, and payment actions.
Config keys: dedupeKey, window, onDuplicate policy, outputVar.
Route outcomes: `new`, `duplicate`, `failed`.
Expected edge configuration: wire `new` to the normal success path, `duplicate` to reuse/update handling, and `failed` to a safe fallback.
Design key per business object type (lead, payment, ticket, appointment) to avoid over-blocking.
Window selection should match business behavior (for example 24h for duplicate ticket prevention).
Allow correction workflows with `update_existing` or `reuse_existing` where user intent is to modify previous submission.
Webhook dedupe should rely on provider event IDs whenever available.
Production examples: repeated lead form submit; repeated webhook; double payment click; duplicate appointment submit; repeated complaint ticket.

Node 13 - Rate Limit / Abuse Protection

Purpose: protect platform from spam loops, OTP abuse, and cost-heavy repeated actions.
Config keys: key, limit, window, bypass roles, emergency bypass, outputVar.
Route outcomes: `allowed`, `blocked`, `failed`.
Expected edge configuration: wire `allowed` to the normal path, `blocked` to a user-safe fallback or retry branch, and `failed` to a safe error path.
Use per-user/per-phone/per-event keys based on abuse surface.
Set role-based bypass for trusted internal users and controlled test traffic.
Keep emergency bypass available for life-critical healthcare flows with extra audit visibility.
Separate end-user rate limits from provider retry traffic where needed.
Production examples: AI call rate control; OTP retry throttle; spam message cap; webhook replay throttle; loop breaker for malicious triggers.

Node 14 - Template Message (WhatsApp critical)

Purpose: send approved template-based messages, especially for out-of-session WhatsApp communication.
Config keys: channel, templateName, language, variables, to, category, outputVar.
Route outcomes: `sent`, `template_not_approved`, `variable_missing`, `failed`.
Validate template approval and language variant before dispatch.
Validate variable slots and media header requirements before send.
Respect user opt-out and promotional restrictions.
Track provider message reference for delivery audit and support follow-up.
Expected edge configuration: wire all four outcomes (`sent`, `template_not_approved`, `variable_missing`, `failed`) to the correct follow-up step; branch later if you need extra business logic.
Production examples: appointment reminder template; payment due template; order update template; 24h re-engagement template; promotion campaign with compliance checks.

Production rollout checklist for advanced nodes

Every new node has at least one success route and one failure/fallback route connected.
All node output variables are named and reused consistently by downstream steps.
Timezone, dedupe key, and tenant isolation are validated for scheduling/record/webhook paths.
Sensitive data handling (PII/medical/financial) is masked in logs and documented in retention controls.
Approval, audit, and analytics signals are available in dashboards before launch.
Cross-channel QA matrix executed for web, WhatsApp, and Telegram before production activation.
Auto-close timeout behavior tested with non-response and late-response scenarios.
Run incident drill: provider failure + retry + fallback + handover recovery.

Operational Checklist

OKAll 14 advanced nodes are documented with config, routes, and edge cases.
OKCross-channel parity and inactivity auto-close behavior is defined and tested.
OKConcern Resolution AI output formatting avoids source leakage in user-visible text.
OKTemplate-message compliance checks (approval/variables/opt-out) are operational.
OKProduction examples are mapped to real business workflows before go-live.

Next Action

Apply this guide in your workspace and keep notes for your team in one shared SOP so onboarding and support remain consistent.

Open Workspace Browse More Docs

Loading page...

Flow Node Automation Playbook (Production Detailed)

Cross-channel baseline requirements (Web, WhatsApp, Telegram)

Concern Resolution AI output rules

Node 1 - Scheduler / Reminder

Node 2 - Database / Record

Node 3 - Webhook Trigger

Node 4 - Human Approval

Node 5 - File Processor / OCR

Node 6 - Unified Notification

Node 7 - Wait Until / Date-Time Condition

Node 8 - Analytics / Track Event

Node 9 - Audit Log

Node 10 - Language Detect / Translate

Node 11 - Queue / Assignment

Node 12 - Dedupe

Node 13 - Rate Limit / Abuse Protection

Node 14 - Template Message (WhatsApp critical)

Production rollout checklist for advanced nodes

Operational Checklist

Related Guides

Next Action

Flow Node Automation Playbook (Production Detailed)

Cross-channel baseline requirements (Web, WhatsApp, Telegram)

Concern Resolution AI output rules

Node 1 - Scheduler / Reminder

Node 2 - Database / Record

Node 3 - Webhook Trigger

Node 4 - Human Approval

Node 5 - File Processor / OCR

Node 6 - Unified Notification

Node 7 - Wait Until / Date-Time Condition

Node 8 - Analytics / Track Event

Node 9 - Audit Log

Node 10 - Language Detect / Translate

Node 11 - Queue / Assignment

Node 12 - Dedupe

Node 13 - Rate Limit / Abuse Protection

Node 14 - Template Message (WhatsApp critical)

Production rollout checklist for advanced nodes

Operational Checklist

Related Guides

Next Action