Skip to main content

Branch Bot Response Logic — Customer/Contact Field

Extend Branch Bot Response in Qontak One so bot builders can branch conversations on Customer/Contact fields (BSUID/phone, name, email, job title, dropdown custom fields…), handling customer validation and routing through configuration alone instead of custom logic or external API nodes. At runtime the bot identifies the current contact, fetches their attributes from the Mekari CDP, and evaluates the configured conditions with type-aware operators and safe fallbacks.

Two forcing functions: META's transition from raw phone numbers to BSUID, and the 21 CIDs still on legacy systems because Qontak One could not handle their validation/routing use cases.

Recorded retroactively (2026-07-27). This initiative was built and GA'd in 2026-Q2 without ever being documented in this repo. It was reconstructed from the Confluence PRD and Epic BOT-3864's board contents while auditing an unparented defect (BOT-4308). See documentations/2026-07-27-retroactive-record.md for what was inferred versus confirmed, and the open items it surfaced.

Scope Changes​

  • Backend — read-only CDP attribute fetch service; CUSTOMER_FIELD branch type accepted on the V2 bot-response branch create + update endpoints (parameters JSONB on intent_api_response_conditions); type-aware operator evaluation engine in the send/resolve path; 3s timeout with fail-safe to the default branch.
  • Frontend — 3-step inline condition editor (field → operator → value) in the Branch Bot node; dynamic operator mapping by field type; type-aware input validation; schema-driven field selector that filters unsupported field types.
  • Design — Figma for the 3-step inline condition editor (Wulan Febyazzahra Putri).

QA Lane​

Lane B — keeps a human QA gate. Two triggers: real-time (the CDP fetch happens on the live conversation path under a 2–3 second SLA, with timeout fallback behaviour that only a human can sensibly validate end-to-end) and security/PII (the bot reads customer attributes under strictly read-only credentials and must not persist them in flow logs). QA execution ran as board tasks (BOT-4118, BOT-4132, BOT-4182, BOT-4282, BOT-4365); no E2E specs exist in tests/ for this initiative, so the Lane-A entry bar is unmet regardless. Classified 2026-07-27.

Progress​

100% — 11 of 11 Jira Stories Done as of 2026-07-27. Effort was never sized in man-days, so progress_done_days stays TBD and this figure is story-count-based (the same convention the roadmap uses for unsized buckets).

Two GA dates, both real. The PRD launch plan targeted 2026-04-01 for Qontak One, with UI configuration to follow. The production rollout of the branch customer field behind the enable_branch_customer_field flag was requested and confirmed on 2026-07-09, gated by a feature-flag enablement document circulated for team approval — see documentations/2026-07-09-production-rollout-feature-flag-approval.md. Treat 2026-04-01 as planned GA and 2026-07-09 as the actual production enablement.

The five Stories that had been left To Do under a closed Epic — BOT-4044, BOT-4045, BOT-4047, BOT-4048, BOT-4052 — were closed on 2026-07-27 on the DRI's confirmation that the work had already deployed, resolving the Epic-vs-Stories inconsistency. All 11 Stories under BOT-3864 are now Done.

Still open: the defect BOT-4308 (To Do, intermittent 500 on saving a second condition), now parented to BOT-3864.

Contents​

Jira​

Epic BOT-3864 — "26Q2 Branch Bot Response Logic: Customer/Contact Field" (11 Stories, ~35 Tasks, 2026-02-26 → 2026-06-24). The Epic already follows this repo's per-user-story convention, so PRD §8 story ids map 1:1 onto its Stories; the mapping is the Jira column of the PRD's §8 table.