Represent regional variation through configuration, not CRM forks
Legitimate local differences belong in declared configuration points and, rarely, registered extensions—never in copies of the global data model or lifecycle.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01Context
A global CRM serves subsidiaries with genuinely different legal rules, approval thresholds, sales channels and local ERPs. Each rollout copied record types, automations and layouts per country. Global changes now need testing in every subsidiary, and global reports need country corrections.
02Decision drivers
- D01
One lifecycle and data model for global reporting
- D02
Legal and fiscal differences are real
- D03
The shared platform must stay upgradeable
- D04
Local teams need controlled autonomy
03Options considered
Country copies of the configuration
Fast first rollouts
Cost: Every global change multiplies; the models drift apartA separate platform per region
Unrelated businesses
Cost: No shared customer or pipeline viewGlobal core, configuration points, registered extensions
A shared model with legitimate differences
Cost: Needs a variation register and governance04Decision
Keep the lifecycle, canonical data concepts and reporting semantics in a global core. Express approved variation through declared configuration points—thresholds, assignment, local roles and selected validation. Allow local extensions only for legal, fiscal or ERP constraints, registered with an owner and a review date. Absorb ERP differences in the integration layer, not in the CRM model.
05Consequences
- A global release is tested once per configuration point, not once per country.
- Local fields are declared extensions; global fields are never redefined.
- Reports stay comparable because stage and KPI definitions cannot vary.
- Every extension has an owner and a review date—and can be retired.
06Revisit when
A subsidiary’s business diverges enough to need its own lifecycle.
The platform gains native, upgrade-safe support for local variants.
07Where this decision is applied
Cases that take this decision, and why it matters there.
- Systems case / 03Designing a global CRM without forking the operating modelSeparating the global CRM core from configurable variation and rare local extensions—so the platform stays upgradeable and reports stay comparable.
- Data case / 05Evolving commercial analytics from single-currency to multi-currencyKeeping the original amount as the fact and the reporting amount as a versioned, derived view—with a declared rate policy for actuals, targets and thresholds, and V1 history migrated without restatement.
- RevOps case / 03Designing pipeline governance across multiple commercial motionsCommon governance—qualified pipeline, outcomes, forecast categories, review format—with motion-specific stages, forecast logic and ageing benchmarks, so the pipeline stays comparable without forcing every team into one process.
- Operating-model case / 01Designing a global commercial operating model across subsidiariesOne commercial operating model for many subsidiaries: a global core, governed local variation, ownership that survives handoffs, a governance model with decision rights, clear system responsibilities and KPIs that stay comparable.