Center of Excellence: 15 Business Units, One Architecture

Situation

TotalEnergies had adopted Salesforce across multiple business units over the course of five years. B2B energy sales in Europe ran on Sales Cloud. Lubricants used a separate Salesforce org for distributor management. Renewable energy had built their own implementation. Corporate services ran yet another. Each business unit had procured, built, and maintained their Salesforce implementation independently, with separate contracts, separate administrators, and separate architectural decisions.

The result was a Salesforce estate with four distinct orgs, conflicting data models, zero knowledge sharing between teams, and no ability to report at the group level on Salesforce-related metrics. A question as simple as “how many Salesforce users does TotalEnergies have globally?” could not be answered without manually aggregating data from four separate systems.

The strategic challenge was compounded by a planned expansion: TotalEnergies was adding five new business units to Salesforce over the following 18 months. Without intervention, the fragmented architecture would scale with each addition — more silos, more technical debt, more governance gaps. The business unit heads had no visibility into what other units had built. Teams were solving the same architectural problems independently, billing the same integration work multiple times.

Leadership decided to establish a Salesforce Center of Excellence to govern the existing estate, rationalize where possible, and create a governance framework that would ensure new implementations were built to a common standard.

Diagnosis

A technical assessment of all four existing orgs revealed the scope of the problem. The four implementations had accumulated 400+ active Apex classes, 1,200+ custom fields, and over 200 active flows — with significant duplication across orgs. Two orgs had been built by the same SI and shared 60% of their technical components, yet maintained separate code bases that had diverged over three years of parallel maintenance.

Data governance was absent. There were no naming conventions enforced, no field-level documentation standards, no test coverage requirements, and no deployment process. Configuration changes were made directly in production in two of the four orgs. One org had not been backed up in 18 months.

The 8M+ customer and partner records across the estate were modeled inconsistently. A “distributor” in the lubricants org was an Account; in the renewables org, it was a custom object. There was no master data management strategy, no deduplication process, and no single source of truth for any entity type.

For the data foundation required to support future Agentforce and Data Cloud deployment — a stated priority on TotalEnergies’ Salesforce roadmap — this architecture was inadequate. You cannot build intelligent cross-business-unit automation on four fragmented data models.

Action

Phase 1: CoE Architecture Design

The Center of Excellence was designed around three pillars: governance, enablement, and architecture standards.

Governance established the structures for decision-making across the Salesforce estate. A Salesforce Architecture Review Board was created, with representation from IT, business unit leads, and the central CoE team. All architectural decisions above a defined complexity threshold required ARB sign-off. An expedited review process handled urgent requests without creating bottlenecks.

A development lifecycle process was defined and enforced: all code and configuration changes through version control (Salesforce CLI + Git), mandatory peer review for all Apex and Flow changes, 80% test coverage requirement for Apex, and change set promotion through Sandbox → UAT → Production. The two orgs making production changes directly were put on a mandatory process remediation plan.

Phase 2: Architecture Rationalization

The two orgs with 60% shared components were merged into a single multi-org architecture with a shared component library. Rather than a full org merge (high risk, high disruption), a shared metadata strategy was implemented: common Apex utilities, shared Lightning Web Components, and standardized integration patterns were published to a shared repository and deployed to both orgs as managed packages.

The data model was rationalized toward a canonical standard: a group-wide Account model that accommodated the different entity types (distributor, corporate customer, government body) across business units, using record types and custom metadata for business unit-specific configurations. This reduced the number of custom objects by 40% across the estate.

A master data management strategy was designed for the 8M+ records: deduplication rules, data stewardship assignments, and a data quality scoring model that measured completeness, accuracy, and freshness by record type and business unit.

Phase 3: CoE Enablement and Scaling

The CoE managed the onboarding of five new business units over 12 months. Each onboarding followed a structured process: architecture assessment of existing systems, mapping to the canonical data model, implementation against the defined standards, and handoff to business unit administrators trained in CoE governance processes.

Architecture documentation was created for every component of the estate: data dictionary, integration catalog, technical debt register, and a live architecture diagram updated with each significant change. For the first time, TotalEnergies had a complete view of their Salesforce estate.

The enablement program trained 200+ consultants — both internal IT staff and external SI partners — in CoE standards. Standard operating procedures covered everything from field naming conventions to change control processes. An internal certification track ensured all consultants working on TotalEnergies Salesforce could demonstrate standards compliance.

Result

TotalEnergies consolidated 15 business units under a unified Salesforce governance framework, with 8M+ records governed under consistent data quality standards for the first time. The fragmented, independently maintained estate became a managed, documented, and continuously monitored platform.

Development efficiency improved materially. Shared components reduced duplication: the common Apex library and shared Lightning Web Components eliminated approximately 60,000 lines of duplicated code across the estate. New implementation projects for incoming business units deployed 40% faster using the standardized architecture templates versus ad-hoc builds.

The architecture rationalization also prepared the estate for future strategic initiatives. With a canonical data model, consistent governance processes, and a clean master data foundation, TotalEnergies’ Salesforce environment is positioned for Data Cloud implementation across business units — enabling cross-BU customer analytics, unified partner data, and Agentforce deployment on a foundation that can support enterprise-scale AI.

The CoE model itself became a reference architecture within TotalEnergies’ broader digital transformation program, with the governance framework and enablement approach applied to other enterprise platforms.

Technologies used: Salesforce Sales Cloud (multi-org), Salesforce CLI, Git (version control), Managed Packages, Lightning Web Components, Apex, custom metadata types, Salesforce DX deployment pipeline