Skip to main content

RFC — Guard the legacy CRM contact page for Qontak One — redirect to CDP customer details

Bucket item: A8 · Class: 🔴 Expedite (reclassified 2026-07-21; queued in Jovi's Sprint 2 plan) · Jira Story: TF-3561 (execution Tasks: TF-3540, TF-3541) · Epic: TF-3500

Context / Problem​

Reported in Slack (#qontak-one-support thread, 2026-07-18/2026-07-21, Zhelia Alifa / Shidqon Famulaqih / Giovanni Massimiliano "Jovi" / Azani Ramadhan / Nourma Jennie Aisyiyah):

How to repro: in Qontak One, open company index v3 → pick a company with an associated customer → click the customer icon in the "associated" column → redirected to the legacy CRM contact edit page. Expected: redirect to the CDP details page, /customer/{id}.

Root cause (confirmed by Zhelia, 2026-07-18): the v2.7 endpoint company v3 calls for the "associated" column only exposes crm_leads_slug (the CRM contact id); it carries no qontak_customer_id-based slug to link to CDP, so the FE has nothing to redirect to except the legacy CRM contact page.

Two-track fix agreed in the thread:

  • CRM (short-term, already ticketed): on Qontak One tenants (unified_app = TRUE), make the associated-contact icon non-clickable in company v3 rather than send it to the wrong page — QON-17428.
  • CRM (long-term, not yet ticketed as of this RFC): BE adds qontak_customer_slugs to the v2.7 endpoint; FE adjusts company v3 to redirect straight to CDP.
  • CDP (this RFC's scope): independent of whether CRM's redirect is fixed, a Qontak One user can still land on the legacy CRM contact page by navigating directly to its URL (bookmark, shared link, browser history, another surface that still links there). Jovi confirmed CDP will help guard that: "bisa2 mba, jadi ini restriction hanya untuk user qontak one dan ini redirect ke page CDP ya?" — restrict/redirect, scoped to Qontak One users only.

Open — not resolved in the thread:

  1. The legacy contact page is confirmed to exist in both CRM v1 and v2 (Nourma, 2026-07-18), but Jovi could not locate the v2 file during the thread ("ini untuk yg crm v2 page contact aku ga nemu filenya, ada dimana yak?") — the exact repo/route for both v1 and v2 still needs confirming before implementation.
  2. Whether the guard is a hard restrict (block + error) or a redirect to the correct CDP /customer/{id} — the thread's own framing was "restrict access atau lempar ke URL CDP yg bener" (Zhelia, 2026-07-18); Jovi's later confirmation ("...dan ini redirect ke page CDP ya?") leans toward redirect, but this wasn't confirmed as a final decision.
  3. Dependency on sibling bucket item A6 (TF-3517, crm-data-id-sync-back-cdp-created-contacts.md): redirecting a legacy CRM contact URL to /customer/{id} requires resolving that contact's qontak_customer_id — the same CRM→CDP id-lookup gap A6 is fixing for CDP-originated contacts. Confirm whether this guard can reuse that lookup once A6 lands, or needs its own resolution path for contacts that aren't CDP-originated.
  4. No Jira ticket exists yet for the CDP-side guard — Jovi said he'd file one ("ok gw bikin dl tiketnya", 2026-07-20) but none was linked in the thread as of 2026-07-21.

Proposed change​

Add a route guard on the legacy CRM contact page(s) (v1 and v2, once located) that, for unified_app = TRUE (Qontak One) tenants, either blocks the page or redirects to the equivalent CDP customer details page (/customer/{id}), rather than silently rendering the legacy page for force-navigated URLs.

Execution plan (call to action)​

  1. Confirm the CRM v1 and v2 contact-page routes/files (repo, path) — open item 1 above.
  2. Decide restrict-vs-redirect (open item 2) with Zhelia/Jovi/Azani before implementation.
  3. Resolve the qontak_customer_id lookup path for the guard (open item 3) — check whether A6 (TF-3517) covers it or a separate lookup is needed for non-CDP-originated contacts.
  4. Implement the guard scoped strictly to unified_app = TRUE tenants; non-Qontak-One tenants must see no behavior change.
  5. File the CDP-side Jira ticket (open item 4) and mint the bucket Story under Epic TF-3500.

Risks & rollback​

  • Risk: scoping the guard incorrectly (e.g. matching on the wrong tenant flag) could block legitimate non-Qontak-One CRM users from their own legacy contact page.
  • Rollback: the guard is additive (a route check); removing it restores current (buggy) behavior with no data changes involved.

Open questions​

See "Open — not resolved in the thread" above (1–4). None of these were settled as of 2026-07-21; this RFC should not move past draft until at least (1) and (2) are confirmed with CRM/CDP leads.