Standardising Dynamics 365 and Power Platform Across Regions That Work Differently

Why do global Dynamics 365 templates fail in regions that work differently?

Most global templates fail quietly rather than dramatically. Headquarters designs a model in workshops with the largest region, calls it the global template, and deploys it everywhere. Smaller regions find that it cannot record their tax identifiers, does not reflect how their distributors work and asks for approvals their market does not need. They comply on paper and keep the real work in spreadsheets, local tools or a copy of the solution someone modified directly in production. Two years later the group has one CRM in name and several in practice.

The cause is almost never the platform. It is a template that standardised too much of the wrong things and too little of the right ones, with no legitimate way for a region to be different.

• Designed centrally, used locally by nobody: the template matches the headquarters process and no region adopts it fully.
• Everything declared global: every local difference becomes a change request, so regions stop asking and start working around the system.
• Nothing declared global: each region customises freely, and group reporting depends on manual mapping every quarter.
• Unmanaged changes in regional production: a quick local fix edits core components, and the next core release overwrites it or cannot be installed.
• No owner for the core: nobody has authority to say no, so the template drifts toward whichever region shouts loudest.

What must be identical across every region, and what should stay local?

The test is simple: a thing is core if the group cannot report, share customers or move people between regions without it being identical. A thing is local if it is driven by law, market structure or language, or if making it identical would only move the difference into a spreadsheet. Your compliance and tax teams define the legal requirements per country; the table is about where each requirement lives in the system.

How do you settle core versus local when regions disagree?

Disagreement is normal and useful, provided it is resolved by criteria written before the arguments start rather than by seniority. We run the core-versus-local decision as a short, documented series of workshops with each region represented, and each contested element goes through the same questions.

• Does group reporting, a shared customer or a cross-region process break if this differs? If yes, it is core.
• Is the difference required by law or regulation in that country, confirmed by your own legal or compliance team? If yes, it is local, inside a core pattern where possible.
• Is the difference a genuine market difference, or a habit? Habits can be changed; market structure usually cannot.
• Would making it identical move the real process into a spreadsheet? If yes, keep it local.
• Can the difference be expressed as configuration data, such as a threshold or a list of values, rather than as a different design? If yes, make the mechanism core and the values local.
• Record each decision, its reason and its owner, so the next region to join does not reopen it from scratch.

What does a core managed solution plus regional extension solutions look like?

The architecture turns the core-versus-local decision into something the platform enforces. The core is built once, released as a managed solution, and installed in every production environment. Each region has an extension solution that depends on the core and adds what that region needs. Regions add; they do not edit core components. The mechanics of solutions, source control, managed deployment and pipelines are covered in our Power Platform ALM guide and are not repeated here.

Which design rules keep regional extensions from breaking the core?

Layering works when a few rules are applied without exception. Most of the damage in multi-region estates comes from one region editing a core component because it was quicker, which creates a layer the next core release has to fight.

• Add, do not modify: regional solutions add forms, views, columns and flows rather than editing core forms or core logic. If a region needs a different form, it gets its own form, assigned by security role.
• Shared choice lists stay core: stages and reporting dimensions are global choices owned by the core; regions do not add values to them locally.
• Mechanism core, values local: approvals, validations and routing read thresholds and approvers from configuration data, so a new limit is a data change, not a solution change.
• Local identifiers in a related table: a registration identifier table with a type and country, rather than a new column on the account for every country.
• No unmanaged changes in production, in any region, including "just this once".
• Environment variables and connection references for anything that differs between environments, so the same solution installs everywhere.
• One publisher and prefix convention for the core and a documented convention for regional extensions, so ownership of every component is visible.

Should regions share one Dynamics 365 environment or have their own?

Both designs work, and the choice is driven more by data residency and operational independence than by preference. Some settings, such as the base currency and base language of an environment, are fixed when the environment is created, so this decision has to be made before the build rather than revisited later.

What governance stops regions from forking the template?

Governance has to make the legitimate route faster than the workaround. If a regional change request takes a quarter, regions will fork; if it takes a sprint and has a clear answer, most will not.

• A design authority with regional representation that owns the core and decides whether a request is core, regional or declined, against the written criteria.
• Tiered change requests: configuration data changes handled by the region, regional extension changes reviewed lightly, core changes planned into the core release.
• A regular core release cadence that regions can plan around, with release notes and a test window in each region.
• Regional product owners with real authority over their extension, so they own local adoption instead of blaming the centre.
• Deployment only through pipelines, with production access for makers removed, and Power Platform data policies and environment strategy applied consistently.
• A quarterly review of drift: unmanaged layers, unused regional components and requests that keep being declined, which usually signal a core decision to revisit.

How should a multi-region rollout be sequenced?

One pilot region, measurable outcomes, then waves. Picking the pilot is a judgement call: it should be representative enough to test the core, supportive enough to engage, and not the headquarters region, because the headquarters region is the one the template was already designed around.

What if regions already run different CRMs or acquired companies bring their own?

Then standardisation starts with consolidation, and the order matters. Where an acquired company must meet a reporting deadline before its CRM can be retired, our guide to merging two CRMs after an acquisition covers the reporting layer, key conforming and retiring systems one at a time. The core-versus-local model on this page is what the surviving system should look like afterwards.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. Some regions or subsidiaries do not fit Microsoft licensing at all, for example large numbers of light users or hosting rules that require their own infrastructure. For those, a custom CRM on React, Node.js, PostgreSQL or .NET can implement the same core customer master, stages and reporting dimensions and feed group reporting, so the standard is preserved even where the platform differs.

What part of a multi-region programme does Solzet deliver?

Senior consultants and full-stack developers with 8+ years of Dynamics 365 Customer Engagement and Power Platform delivery run the core-versus-local workshops, design the core and regional solution architecture and environment strategy, build the core and regional extensions, set up ALM and pipelines, and support regional waves including data migration. Delivery is remote from Yerevan, Armenia, working with regions in the UK, Germany, the Netherlands, the US and elsewhere through Teams, with any onsite workshops arranged case by case. See our Dynamics 365 consulting service for how engagements run.

• Covered: Dynamics 365 Sales, Customer Service, Field Service and Customer Insights, Dataverse, Power Apps, Power Automate, Power Pages, integrations and PCF controls.
• Not covered: Dynamics 365 Finance, Business Central, Finance and Operations or any ERP rollout; we integrate with the ERP your group runs.
• Not provided: tax or legal advice; country requirements come from your legal, tax and compliance teams, and we implement them.
• If an earlier regional rollout has stalled, a health check of the existing estate is usually the first step.