Carlos EscasainCommercial Systems & Process Architect
ENES

Systems case / 03 · Global core vs. configurable variation

Designing a global CRM without forking the operating model

A fictional case about platform variation: a global CRM core, declared configuration points, a variation register and a release model that keeps every subsidiary on one platform.

Fictional scenario8 min readUpdated 28 Sep 2026
Fictional scenario

Independently created. Contains no employer or client implementation detail, internal names or figures.

01The outcome

One global core that every subsidiary runs, variation expressed as configuration at declared points, and local extensions that are rare, registered and removable.

The reality

Subsidiaries need genuinely different rules, and every difference so far has become a copy of the configuration.

Architecture question

What belongs in the global core, what is configurable—and what must never be forked?

Key decision

Absorb regional variation in configuration and in the integration layer—never by forking the shared data model or lifecycle.

ContextA global B2B company runs one CRM across subsidiaries in several regions. Legal requirements, approval thresholds, address rules, sales channels and local ERPs genuinely differ. Earlier rollouts absorbed each difference by copying record types, automations and page layouts per country—until nobody could change the global model without breaking a subsidiary.

Disciplines involvedSystems & CRM ArchitectureDigital Operating ModelData & Integrations
Systems and partiesGlobal CRMIntegration layerLocal ERPsData platform

02The reality · current state

What the platform looks like today.

  • Each country has its own copy of record types, automations and layouts
  • A global change needs regression testing in every subsidiary
  • Legal requirements and local preferences are implemented the same way
  • Local ERP constraints leak into the shared data model
  • Global reports need country-specific corrections to be comparable
  • Nobody can say which differences are still needed

03System responsibilities

Every platform, one job—and a boundary.

What each platform owns in this design, and what it deliberately does not. These are the responsibilities for this context, not universal rules.

Global CRM

One commercial platform for every subsidiary
Owns
  • Global lifecycle and stage semantics
  • Canonical commercial concepts
  • Declared configuration points
  • Shared reporting semantics
Deliberately does not own
  • Local legal or tax validation logic
  • ERP-specific customer structures
  • Country copies of the data model

Integration layer

One CRM model, several ERPs
Owns
  • Mapping to each local ERP
  • Entity-specific enrichment and defaults
  • Delivery state per legal entity
Deliberately does not own
  • Commercial rules
  • What the CRM shows to users

Local ERPs

Legal and transactional truth per legal entity
Owns
  • Local legal and tax validation
  • Company-code and fiscal structures
  • Local customer and order numbering
Deliberately does not own
  • The commercial lifecycle
  • Global reporting definitions

Data platform

Comparable history across subsidiaries
Owns
  • Harmonized global measures
  • Mapping of local codes to global dimensions
  • Usage of each variant
Deliberately does not own
  • Operational rules or workflow

04Key dimension · Global core vs. configurable variation

Three layers of variation, three different costs

Every difference is placed deliberately. The further it sits from the core, the more it costs to keep—so the register asks for a reason, an owner and a review date.

  1. Global core

    Never varies. Changes go through global governance.

    • Lifecycle stages and exit criteria
    • Canonical data concepts and identifiers
    • Reporting semantics and KPI definitions
    • Role model and sharing principles
    Owner
    Global platform owner
    Cost
    Changed once, for everyone
  2. Configurable variation

    Varies by legal entity through declared configuration—no code, no copies.

    • Approval thresholds and currencies
    • Assignment and territory rules
    • Local roles mapped to global roles
    • Selected validation rules
    Owner
    Regional admins, within global limits
    Cost
    Tested once per configuration point
  3. Local extension

    Only for legal, fiscal or ERP constraints that configuration cannot absorb.

    • Country-specific legal fields
    • Local document output
    • A local ERP mapping in the integration layer
    Owner
    Local owner, approved by the global board
    Cost
    Permanent: upgrade testing, support, comparability

Uncontrolled local customization is not free flexibility. It is a permanent cost on every future release.

05Data authority

Who may create, change, read or derive each concept.

Highlight
Data authority by business concept: which system may create, update, read or derive each concept
Business conceptGlobal CRMIntegrationLocal ERPData platform
Lifecycle stages & definitionsDefined once, globally. No subsidiary may redefine a stage.CreateUpdateReadNo authorityRead
Approval threshold valuesThe structure is global; the values are configuration per legal entity.CreateUpdateNo authorityNo authorityRead
Customer addressCaptured in the CRM with local format rules; validated and owned by the local ERP after creation.CreateReadUpdateRead
Local legal identifiersDeclared local extension fields in the CRM—never a redefined global field.ReadReadCreateUpdateNo authority
Sales channel & business unitA global list with governed local values.CreateUpdateReadReadRead
Global KPI definitionsDefined and governed once, in the data platform. Local targets are data, not definitions.ReadNo authorityNo authorityCreateUpdate

No system owns a whole record here. Authority sits with each concept—and sometimes changes hands when the lifecycle does.

06Candidate architectures

Credible options, judged against these premises.

Rejected

One CRM per region

Very different businesses with little shared process

Cost: Duplicated lifecycle, integration and reporting; no global view
Rejected

One CRM, local copies of record types and automations

Fast first rollouts

Cost: Every global change multiplies; the models drift apart
Selected

Global core, declared configuration points, registered extensions

A shared commercial model with legitimate local differences

Cost: Needs a variation register and governance

07The second layer

Questions that change the architecture.

The core

  1. What belongs in the global core?
  2. Which data model must remain universal?
  3. Which definitions keep global reports comparable?

Configuration

  1. What is configurable locally, and within which limits?
  2. Which rules belong in configuration rather than code?
  3. Who may change a configuration value?

Extensions

  1. What must never be forked?
  2. Who approves variation—and when does it expire?
  3. When does a local requirement justify an architecture change?

08Decisions & outputs

What the work produces.

Architecture decisionADR 006 — Represent regional variation through configuration, not CRM forks
  1. 01Core capability model
  2. 02Global/local variation register
  3. 03Configuration boundaries
  4. 04Extension policy
  5. 05Governance model
  6. 06Release model
Disciplines involvedSystems & CRM ArchitectureDigital Operating ModelData & Integrations