Freezing a global template while three countries demand localisation
A Danish fashion retailer runs Dynamics 365 Supply Chain Management and Finance in Denmark and Sweden. It plans to open legal entities in Poland, Spain, and the United States within 14 months and has committed to a "configure once, deploy many" template. The programme board wants the template frozen at the end of the design phase, but Poland requires JPK/SAF-T filings, Spain requires SII VAT reporting, and the US requires sales and use tax across 12 states with nexus determined per legal entity. Meanwhile the customer service team wants near-real-time visibility of order status and customer credit holds in Dynamics 365 Customer Service, at roughly two million order line updates per month, and has proposed dual-write. The current system already carries 23 country-specific extensions inherited from the Swedish rollout, three of which override the same class. Nine months remain in the programme.
1. How should the architect govern global template versus localisation? What specifically should be frozen?
Read the worked answer
The right answer is to freeze less, not more. Split the template into three layers and govern each differently. Layer one is core configuration - chart of accounts, item and customer masters, number sequences, warehouse topology - frozen after design. Layer two is localisation delivered as Microsoft standard features wherever they exist. Poland's JPK/SAF-T and Spain's SII are standard, Microsoft-maintained capabilities, so building extensions for them creates permanent maintenance for an obligation that changes on the regulator's timetable. Layer three is genuinely local process difference, delivered as country-scoped extensions with a named owner and a scheduled expiry review.
Practically: the design authority approves core changes only; country extensions live in separate models, are reviewed against the core interface, and may never modify shared tables. The 23 Swedish extensions are the real risk - three overriding the same class means the next update breaks unpredictably. Triage them now into retire, convert to extension, or replace with standard. Add a rule that no localisation is built before confirming Microsoft's roadmap for that country, and record the decision, because "we built it before it shipped" is the most expensive kind of customisation.
2. Is dual-write the correct architecture for the Customer Service requirement? Justify your recommendation and describe the alternative.
Read the worked answer
Start by separating what agents need to read from what they must write. Dual-write is near-real-time, bi-directional, table-scoped synchronisation between Finance and Operations and Dataverse. At roughly two million order line updates a month the average is under one per second, so raw volume is not the constraint; burst throughput, service protection limits, message ordering, and the fact that dual-write covers a defined set of tables and maps - not arbitrary queries - are the constraints.
If agents only need to see order status and credit holds, dual-write is the wrong tool. Emit business events to Azure Service Bus and project a slim read model into Dataverse; that is one-directional, tolerates the source being unavailable, and creates no write conflicts. Virtual entities work for low-volume read-only lookups but perform poorly for lists and joins.
If agents must place or release credit holds, dual-write becomes credible for that narrow scope: customer, contact, and the specific hold fields, with column filtering and conflict resolution defined up front. Design for failure - dual-write retries and queues, so no finance process may depend on synchronous completion. Recommend the hybrid, and document which fields are mastered where.