Global Rollout With Data Residency: One Org, Two, or Three?
Helio Grid is a utility equipment manufacturer rolling out a service center for 420 agents in the United States, Germany, and Japan. German law requires that German customer records, including case descriptions and attachments, never leave the EU; Japan has a similar internal policy but permits anonymized records to be exported for defect analysis. Leadership wants one global knowledge base of engineering fixes, one product catalog, and a single executive dashboard. Sales already runs a separate CRM org in each region. Agents handle warranty claims, field dispatch, and spare-parts orders, and about 30% of cases cross regions because equipment is sold globally. The program sponsor wants the fastest possible go-live with minimal custom code, while the security team insists that German agents cannot see US customer data and that US agents cannot see German records. Current volume is 18,000 cases per month, peaking at 2,400 per day during storm season.
1. Recommend a service center instance architecture. Justify the number of instances, where case data lives, and how the global knowledge base and product catalog are delivered.
Read the worked answer
Recommendation: two production service instances, not one global org and not three.
- EU instance: German and other EU case data, attachments, and German-language knowledge approvals stay in an EU region. This satisfies the legal residency requirement outright. A single global org with business units and sharing rules does not solve residency, because records still reside in one database region; sharing rules control visibility, not storage location.
- US plus Japan instance: combine only if Japan's policy is internal and anonymization is enforceable at the integration boundary. If Japanese counsel treats it as a legal restriction, split Japan out; the cost of a third instance is lower than a compliance failure.
- Knowledge: maintain one engineering source of truth and publish approved articles to each instance. Knowledge is lower-risk than case data, but confirm whether German legal treats German-language article content as local data.
- Product catalog: master in one system, sync to both, localize pricing and spare-parts availability.
- Cross-region cases: route through a thin integration passing a case token, product, serial number, and anonymized symptom. Do not replicate customer PII; the receiving instance creates a linked case.
Why not one org: residency is a storage and processing constraint, not a visibility constraint. Why not three: US and Japan share engineering and defect analysis, so a second instance is justified only by policy. Sequence EU first if a legal deadline drives it, with shared data contracts as the long pole, not custom code.
2. The sponsor still expects one executive dashboard across all regions. How would you deliver it without violating residency, and what accuracy tradeoffs must be accepted?
Read the worked answer
A single executive dashboard is achievable, but not by querying across instances in real time.
- Conformed analytics layer: extract case facts from each instance nightly or hourly into a warehouse or analytics tier, then aggregate there. This is the only practical way to get one number across instances.
- Anonymize at the boundary: EU records must be aggregated and stripped of customer identifiers before leaving the region. Define the minimum extract: case count, priority, product, resolution time, region, and outcome. No free-text descriptions or attachments.
- Standardize definitions first: one case taxonomy, one priority scale, one definition of first response and restoration. Otherwise the dashboard is unified but wrong.
- Normalize time: store UTC, expose a reporting-timezone dimension, and never average local timestamps across zones.
- Accept latency: the executive dashboard is near-real-time at best. Operational SLA monitoring belongs inside each instance, where the clock and the queue live.
- Reconcile monthly: compare warehouse totals to instance totals; investigate drift from deleted, merged, or reassigned cases.
Tradeoff to state explicitly to the sponsor: real-time cross-region reporting conflicts with residency and with low customization. Hourly or daily refresh meets executive needs; claiming real-time would force PII replication and is not defensible to legal.
3. Which stated requirements would you challenge or clarify before design sign-off, and why does each matter?
Read the worked answer
Challenge or clarify these before design sign-off:
- 'One global knowledge base': residency may apply to localized article content, not just cases. Clarify whether German-language articles can be authored centrally and where drafts live. This changes the authoring workflow and approval path.
- '30% of cases cross regions': direction and content matter. If the crossing case must carry full customer context, a token-based handoff is insufficient and the design changes. Clarify which fields are genuinely needed at the receiving side.
- 'Fastest go-live with minimal custom code': the cross-instance routing and catalog sync are integrations, not custom code, but they are still schedule risk. Ask whether a manual handoff is acceptable for the first release.
- 'German agents cannot see US data': distinguish customer PII from product and case-pattern data. Defect analysis may legitimately need anonymized US records in the EU, and that is far cheaper than blocking all visibility.
- Master data ownership: who owns product, serial number, and entitlement records across regions? Duplicate ownership causes reconciliation failures that surface as reporting defects later.
- Retention and deletion: German deletion obligations may exceed standard archive behavior and must be designed into the extraction process.
Getting these answered prevents an architecture that satisfies the org chart but fails the regulator.