Enterprise customer auto-linking — solution and scenarios
| Sources | client-resources/Unified-Unified Digital - Enterprise Customer Auto-Linking Solution-211026-135546.pdf (16 pp) · client-resources/Unified-Auto-Linking Scenarios & Open Questions-211026-135759.pdf (2 pp) |
| Type | Confluence page exports |
| Origin | Unified Digital delivery team — individual authors not stated |
| Dated | Exported 2026-10-21 · received 2026-10-26 |
| Release context | Manulife has since stated the MVP ships as two releases: the single dashboard in November 2026, then this MDM auto-link work in June/July 2027 |
What it is
The design for ADS Phase 2, "identity resolution, ECID mapping, auto-linking, MDM foundation for GB and Retirement". The solution page sets out an ownership split (CIAM for credentials, MFA and sessions; MDM for enterprise identity, matching, relationships and product ownership), the ECID, the current match-and-merge rules with per-source attribute coverage, and four scenarios with Mermaid flows:
| # | Customer state | Resolution |
|---|---|---|
| 1 | Has products, no CIAM | Register → real-time MDM search → verification challenge → ECID-to-CIAM link → MDM returns all products |
| 2 | Has CIAM, some products linked | A CIAM Reconciliation Engine compares CIAM links with MDM ownership and auto-links the rest |
| 3 | Has CIAM, more than one ECID | Steward merges; MDM emits CustomerMerged; CIAM mapping updates automatically |
| 4 | More than one CIAM ID | Customer picks a primary profile; the other is disabled and kept for audit. Standard: 1 person = 1 ECID = 1 CIAM |
A four-phase migration closes it: establish ECID, bulk reconciliation (80–90% expected to be perfect matches), a real-time Registration Match API, and finally search-before-create in every business unit. The scenarios page asks two open questions: may SIN be used in matching, and may verifying one product raise a low-confidence match enough to link all products.
It confirms the target's identity model
The core position is ours, and ADR-0006's. "Identity ≠ Customer": CIAM authenticates, MDM resolves the customer, and the ECID (rel_id in section 9 of the target state document, ADR-0006) is a business identifier that survives CIAM and source migrations. Ambiguous matches go to stewardship, merges publish an event that re-keys CIAM, and CIAM never decides which ECID is right. That is the ECID brief's argument, and the client now makes it in its own design. No component of the target changes.
Where it diverges from the target
1. The ECID-to-CIAM link has no named system of record. The ownership table omits it. The architecture view puts an "ECID Mapping Store — Enterprise Cross-ID Registry" between a Customer Link API and MDM, and the login view stores CIAM ID and a UUID in ForgeRock LDAP and again in MDM. In the target, MDM accepts the link and ciam-sync and ecr-sync replicate it. Without that rule, the link table becomes a second registry, which ADR-0006 was written to prevent. The "UUID" in the login view must be the ECID, not ForgeRock's internal _id.
2. A no-match mints a new ECID. Scenario 1 creates a golden record and ECID on no match. The target issues no provisional enterprise identifier: the customer stays pending until evidence or a business unit's ownership event resolves them. Where the customer does hold products, but data quality defeated the match (see the coverage table below), minting creates the duplicate that scenario 3 then needs a steward to merge. It also contradicts the client's own phase 4, search before create.
3. Product discovery reads MDM, possibly on every login. "MDM returns the customer's product relationships" at registration is acceptable. If the login view means MDM on every sign-in, it puts a mastering platform on the request path. The target reads products from the D3 projection and keeps MDM for change events. The flow is synchronous where the target's intake is asynchronous; the two reconcile as a bounded synchronous attempt that falls back to the pending state.
4. Linking and merging run without customer consent. Category B auto-enriches existing profiles, scenario 3 merges by steward decision, and both show a customer one unit's product at another's login. The UCL deck says records "cannot be merged without customer consent", and section 9 lists relationship linking, identity merge and cross-unit data use as consent purposes. A Privacy position is needed before release 2, whereas the roadmap's unified consent epic ends February 2028.
5. There is no unmerge. A wrong merge shows one person's products to another. The target requires an unmerge event that re-keys CIAM, ECR and D3; the document covers merge only.
6. CIAM profile merge (scenario 4) reaches past CIAM. Retiring MID222 must end its sessions (back-channel logout, section 9), move MFA factors, and re-key anything the November MVP stores against the CIAM ID, because the MVP is keyed by CIAM ID. Merging ForgeRock identities is not a standard platform function and needs proving.
7. Search before create is last, and should be first. R1.3 separates the provisioning link (a new enrolment, deterministic, no merge consent) from the resolution link (the back book, probabilistic). Phase 4 is the provisioning link. Every enrolment until it lands adds to the back book that bulk reconciliation has to clear.
The matching evidence weakens the release 2 scope
On our reading of the rule table and the attribute coverage on page 4:
- Group Benefits holds no SIN (Manuconnect: 0%). Retirement holds it for 99.9% of members. Every auto-merge rule needs SIN to match exactly or be missing on both sides, except rule 3. So a GB record merges with a Retirement record only through rule 3: exact name, birth date, address line 1 and postal code. No suspect rule covers that pair either. Release 2's two business units therefore meet through one exact-only rule, which is consistent with "GB currently not fully participating in match/merge". The 80–90% Category A estimate needs its basis.
- Registration inputs do not fit the merge rules. Registration collects postal code but not address line 1, and the last three digits of SIN, which no rule uses. The merge rules compare two source records. A registrant needs a separate search profile and confidence threshold, which the document does not define.
- Email is required at registration, but most Insurance sources hold none (0% for CAPSIL, CATS, CLAS, PS, VAPS, iFAST Seg). Phone is also below 40% for most of them. The recommended out-of-band verification cannot reach those customers, so knowledge-based or product verification becomes their only route. GB is reachable by email for 78% and by phone for 31%.
On the open questions. Question 1: GB holds no SIN, so SIN cannot help the first business unit whatever Legal decides. If SIN is approved, a plain one-way hash is not protection, because the SIN space is small enough to enumerate. Use a keyed hash with the key held in a managed key service. Question 2 is open item 8 in section 19. Verifying one product is evidence for that product. It should extend only to products joined by exact rules (1–7), and each owning unit must accept it. Fuzzy-joined products (rules 8–13) need their own evidence. The registration search can also tell an attacker whether someone is a customer and send them an OTP, so its responses need to be uniform and rate-limited. The data protection section does not mention this.
Impact on the roadmap
The November 2026 release is ADS Phase 1, which v4 already calls the first sliver. Its date is now fixed, and it runs alongside our phase 0 (November to December 2026) and competes for the same SMEs. Release 2 is the problem. v4's recommended path (slide 74) builds the capability later than June/July 2027:
| Epic (v4, slide 74) | Planned | Release 2 needs, by June 2027 | Gap |
|---|---|---|---|
| Latency and throughput POC | Dec 2026 | Also the registration match API and bulk-reconciliation load | Scope, not date |
| MDM integration | Mar–Aug 2027 | Match API, link write and merge events in production | About 2 months |
| Identity linking (ECR crosswalk) | Aug–Oct 2027 | This is release 2 | About 4 months |
| Unified consent | Nov 2027–Feb 2028 | Consent capture for linking and merge | About 5 months, for that purpose only |
| Event path (proven at M1) | Jul 2027, non-production | CustomerMerged consumed in production | About 1 month, in production |
| Identity-proofing policy (open item 8) | Not dated | Decided before build, Q1 2027 | New gate |
| GB match-and-merge onboarding | Not in the plan | GB records matchable against Retirement | New epic |
Manulife has to rule on whether release 2 is built on the MVP or on the target:
- On the MVP (CIAM ID-keyed, outside our foundation). Milestones hold, but identity linking becomes a migration: re-key the MVP-built links to ECID and retire the mapping store as a registry. Work is thrown away, and a second link authority runs for at least a year.
- As the target's identity foundation (our recommendation). Pull MDM integration to January 2027, straight after the POC, and identity linking to April–June 2027. Bring production event publication forward and add a minimum linking-consent capture. MDM becomes the critical path from M0, and identity capacity peaks in Q2 2027, where the Cost Estimations tab already has none after May 2027. In exchange, GB's October 2027 milestone (M2) no longer waits on linking.
Either way, release 2 cannot cover all four scenarios and all units by June/July 2027. Scenarios 1 and 2 for GB and Retirement fit if GB's match-and-merge gap is closed first. Scenario 3 is MDM stewardship work that runs anyway. Scenario 4 and phase 4 belong to later releases.
To confirm with the authors
- Which system is the system of record for the ECID-to-CIAM link, and is the ECID Mapping Store a replica?
- Does every login call MDM, or only registration and reconciliation?
- Is the UUID in the login view the ECID?
- On no match, is an ECID minted for a customer who holds products?
- What is the basis of the 80–90% Category A estimate, and what is it for GB?
- Which rule set scores a registration search, and what counts as high confidence?
- Is there an unmerge path, and what does the customer see after a wrong merge?
- Is release 2 built on the MVP stack or on the target foundation?
- Has Privacy ruled on auto-enrichment and steward merges without customer consent?