RFC — Sticky Agents assignment support (Chat ask), intake placeholder
Bucket item: A6 (26Q3 CDP Adhoc) · Class: 🔴 Expedite (classified 2026-07-21 per Sprint 2 planning direction — see Handoff note on justification status) · Jira Story: TF-3609 · Epic: TF-3477
Re-homed 2026-07-27 from CDP 26Q3 Engineering Initiatives (Epic TF-3500, where it was A10) to the adhoc bucket — a Chat/Omnichannel product ask, not engineering-owned tech debt. The Jira Story was minted under TF-3500 the same day and re-parented to TF-3477 before any work started.
Context / Problem
Raised at Sprint 2 planning (2026-07-21), verbatim: "Butuh support actions set/remove assignment untuk kebutuhan Sticky Agents dari Chat" — Chat/Omnichannel needs CDP to support set and remove assignment actions for their Sticky Agents feature (an agent staying assigned to a returning customer/conversation).
That was the entire input at intake. This RFC is still an intake placeholder, not a design — but the upstream Chat/Design artifacts below (found 2026-07-27) supply the problem statement and a target date that the sprint-planning sentence did not.
Upstream artifacts (Chat / Design — read before scoping)
None of these live in this repo, and CDP owns no artifact under them. Recorded here as the authoritative upstream context for the ask.
| Key | Type / project | Status | What it holds |
|---|---|---|---|
| MKR-5795 | Idea — Mekari Product Discovery | Discovery Backlog | The originating pain point (quoted below) |
| QC-22880 | Epic — Qontak-Chat | To Do | "[26Q3] [AI SDLC] [Qontak One] Contact assignee (sticky agent)" — the Chat-side home; no engineering children yet |
| PXL-9354 | Story — Product Design | To Do | "[26Q3] Contact assignee (sticky agent chat)" — target release August 2026, domain Comms, init type Strategic |
| PXL-9371 · PXL-9376 | Task — Product Design | Done | UXD + UXW "Sticky agent — Inbox" |
| PXL-9424 | Task — Product Design | Done | UXW "Sticky agent — Edge cases" (parented to QC-22880) |
Problem statement, verbatim from MKR-5795:
several clients implement ownership based assignment where a customer has a dedicated agent and cannot be assigned to different agents. Due to such need not being accommodated in Qontak as of yet, the workaround used is to not resolve conversations with customers, resulting in extremely long agent performance report
What's not known yet
What entity CDP is being asked to expose set/remove-assignment support for.Likely answered: every Chat/Design artifact names it "Contact assignee", not conversation assignee — so the target is the CDP-owned contact, and CDP's role is real rather than incidental. Confirm with the Chat squad before designing against it; the CDP-side field/owner semantics (and any overlap withteam_owner_idsfrom Team Owner Field & Team Permission) are still unspecified.- Whether this is a new CDP API (Chat calls CDP to set/remove an assignment reference), a field CDP needs to store/expose for Chat to read, or something else entirely.
- Whether any Frontend (qontak-customer-fe) or Mobile surface is involved, or this is BE-to-BE only. Scope below is provisionally Backend-only until confirmed. Note the Design tasks are Inbox-side (Chat surfaces), which does not rule a CDP surface in or out.
- Why this is classified 🔴 Expedite. No urgency evidence was given at classification time (2026-07-21 sprint planning). The closest thing to real evidence is PXL-9354's August 2026 target against zero CDP-side scope — but that is a design-sheet target, not a commitment CDP has accepted, and QC-22880 has no engineering breakdown behind it either. Confirm the date with the Chat squad, then justify the 🔴 or reclassify.
Proposed change
None yet — there is nothing to design against. Next step is a scoping conversation with the Chat/Omnichannel squad (owners of QC-22880) to pin down the actual API/data contract, which repo(s) are involved, whether the August target is real for the CDP side, and whether Chat has a concrete request (endpoint shape, trigger, timing) or is still exploring. Read the closed UXD/UXW design tasks first — the Inbox flows and edge cases are already drawn, so the contract may be more determined than the intake sentence suggests.
Handoff note
This RFC is step 1 of the bucket's "how the bucket
grows" process. Done 2026-07-27: tracker row
A6 appended and Jira Story TF-3609 minted under Epic TF-3477. Still pending:
- Scope the actual ask with the Chat/Omnichannel squad — this RFC should be rewritten (or replaced) once real requirements exist.
- Confirm the 🔴 Expedite classification or reclassify it, now against PXL-9354's August 2026 target rather than against nothing.
- Ask Chat to link QC-22880 ⇄ TF-3609 from their side. CDP deliberately created no artifact under QC/PXL/MKR — those Epics are Chat's and Design's to own.
Ready for agent execution: no — this is an intake placeholder for an unscoped ask, classified 🔴 Expedite by direct sprint-planning instruction rather than a documented risk analysis. Do not start engineering work against it until the Chat squad's actual requirement is captured here.