Master Data, Data Ownership, Golden Records and the Architecture Decisions That Matter
One of the most common questions I hear when working on enterprise Salesforce architecture is:
“Should Salesforce be the system of record?”
It sounds like a simple question.
It rarely is.
In a small Salesforce implementation, the answer may appear obvious. Salesforce stores Accounts, Contacts, Opportunities, Cases and other business information, so teams naturally start treating Salesforce as the master.
The situation changes completely when Salesforce becomes part of a larger enterprise landscape.
An organization may already have:
- an ERP
- a legacy CRM
- an MDM platform
- a billing platform
- a data warehouse
- a data lake
- marketing platforms
- customer portals
- commerce platforms
- identity platforms
- regional applications
- acquired business systems
- multiple Salesforce orgs
At that point, saying “Salesforce is the source of truth” without defining for what is dangerous.
A mature Salesforce data architecture does not ask:
Where should we store the data?
It asks:
Who owns the data, who can change it, which version is authoritative, and how does the rest of the enterprise consume it?
That is the real data architecture problem.
1. The Architecture Problem Is Not Salesforce
I have seen organizations spend enormous amounts of time debating Salesforce objects, fields, integrations and APIs while missing the fundamental question:
Who owns this data?
That question should come before deciding:
- object design
- integration pattern
- API strategy
- replication strategy
- synchronization frequency
- validation rules
- automation
- MDM implementation
Consider something as simple as:
Customer
Who owns the customer?
It could be:
Salesforce
ERP
MDM
Billing
Legacy CRM
Customer Portal
And there is another possibility that is often overlooked:
Different systems can legitimately own different attributes of the same customer.
For example:
Customer Identity → MDM
Financial Status → ERP
Sales Relationship → Salesforce
Marketing Consent → Marketing Platform
Customer Authentication → Identity Platform
There is no requirement that one system own every piece of information about an entity.
This is where enterprise data architecture becomes interesting.
2. System of Record Is Not the Same as System of Data
I prefer to distinguish between several concepts that are often incorrectly used interchangeably.
System of Record
The authoritative system responsible for a particular business data domain or attribute.
System of Entry
The system where a user or application captures information.
System of Reference
A system from which other applications consume information.
System of Engagement
The system where users interact with the business process.
System of Insight
The system where data is aggregated and analyzed.
These can all be different systems.
For example:
Customer
|
+------------+-------------+
| | |
MDM Salesforce ERP
| | |
Identity Engagement Finance
Salesforce can be the primary system of engagement while MDM remains the system of record for customer identity.
That distinction alone prevents many architectural mistakes.
3. My First Rule: Never Say “Salesforce Is the Source of Truth”
When someone says:
“Salesforce will be the source of truth.”
My next question is:
“For which business domain?”
And then:
“For which attributes?”
For example, Salesforce may own:
- Account segmentation
- Sales territory
- Opportunity ownership
- Customer relationship status
while another system owns:
- legal customer identity
- tax information
- payment terms
- bank information
- financial status
This leads to a more useful architecture:
| Data Domain | Authoritative Owner |
|---|---|
| Customer identity | MDM |
| Legal entity | ERP / MDM |
| Sales relationship | Salesforce |
| Opportunity | Salesforce |
| Invoice | ERP |
| Payment | ERP |
| Product catalog | Product Master |
| Pricing | Pricing Platform |
| Marketing consent | Consent Platform |
The important word is authoritative.
4. Data Ownership Must Be Explicit
One of the strongest lessons I have learned from enterprise architecture is that unowned data eventually becomes duplicated data.
When ownership is unclear, multiple systems start modifying the same information.
For example:
Salesforce
|
+---- Customer Name ----+
| |
ERP MDM
| |
+----------+------------+
|
Which one is correct?
Now integration teams start building synchronization logic.
Salesforce updates ERP.
ERP updates Salesforce.
MDM updates Salesforce.
Salesforce updates MDM.
Soon the architecture looks like:
Salesforce <----> ERP
^ ^
| |
+----> MDM <---+
This is where data synchronization becomes a permanent architecture problem.
The better approach is:
Establish ownership before establishing synchronization.
5. The Data Ownership Matrix
For large Salesforce implementations, I strongly recommend creating a Data Ownership Matrix before designing integrations.
For example:
| Entity / Attribute | Owner | Salesforce Role | Other Consumers |
|---|---|---|---|
| Customer Legal Name | MDM | Reference | ERP, Marketing |
| Customer Segment | Salesforce | Master | Data Platform |
| Tax ID | ERP/MDM | Reference | Finance |
| Opportunity | Salesforce | Master | ERP, BI |
| Invoice | ERP | Reference | Salesforce |
| Product | Product Master | Reference | Salesforce, ERP |
| Price | Pricing System | Reference | Salesforce |
| Case | Salesforce | Master | Data Platform |
This matrix becomes one of the most valuable architecture artifacts in the program.
It answers questions that API specifications cannot answer.
6. Ownership Is Often Attribute-Level
This is where many data architectures become unnecessarily simplistic.
Suppose we have:
Account
Instead of saying:
Salesforce owns Account.
We should ask:
Account
├── Legal Name
├── Address
├── Tax Identifier
├── Credit Status
├── Customer Segment
├── Sales Territory
├── Account Owner
└── Relationship Status
Different attributes may have different owners.
For example:
Legal Name → MDM
Tax Identifier → ERP/MDM
Credit Status → ERP
Sales Territory → Salesforce
Account Owner → Salesforce
Customer Segment → Salesforce
This is a far more realistic representation of enterprise data ownership.
7. What Is Master Data?
Master data represents important business entities that are shared across multiple processes and systems.
Typical examples include:
- Customer
- Account
- Contact
- Product
- Supplier
- Employee
- Location
- Legal Entity
Master data tends to have a longer lifecycle than transactional data.
For example:
Customer
may participate in:
Sales
Billing
Support
Marketing
Commerce
Finance
Analytics
AI
That makes customer data particularly important to govern.
8. Master Data vs Transaction Data
The distinction is important.
Master Data
Describes business entities.
Examples:
Customer
Product
Supplier
Location
Transaction Data
Describes business activity involving those entities.
Examples:
Order
Invoice
Payment
Opportunity
Case
Shipment
A useful model is:
Master Data
|
+---- Customer
+---- Product
+---- Location
|
v
Transactions
|
+---- Order
+---- Invoice
+---- Opportunity
+---- Shipment
The architecture for master data and transaction data should not automatically be identical.
9. Salesforce Is Often a System of Engagement, Not the Enterprise Master
This is one of the most important points I would emphasize to architects.
Salesforce is exceptionally good at managing customer-facing business processes.
That does not automatically mean it should become the enterprise master for every customer attribute.
Salesforce may be the system where sales teams:
- manage relationships
- qualify opportunities
- manage accounts
- work leads
- resolve cases
- manage customer interactions
Meanwhile, enterprise master data may be governed elsewhere.
Therefore:
System of engagement and system of record are architectural roles, not product labels.
10. The Golden Record
The term Golden Record is frequently misunderstood.
A golden record is not simply:
“The Salesforce Account record.”
It represents the best governed representation of a business entity assembled from authoritative information.
Imagine:
Salesforce
Customer:
ABC Corporation
ERP
Customer:
ABC Corp Ltd
Legacy CRM
Customer:
ABC Corp.
MDM
Customer:
ABC Corporation Ltd
Which one is correct?
An MDM process may determine:
Golden Customer
Global Customer ID: CUST-001234
Legal Name: ABC Corporation Ltd
Address: ...
Tax ID: ...
The golden record becomes the enterprise reference representation.
Salesforce can then maintain its own representation while holding the enterprise identifier.
11. Golden Record Does Not Mean One Giant Record
This is another distinction I consider extremely important.
Some teams interpret golden record as:
“Every attribute from every system should be merged into one master record.”
That can create an enormous centralized model.
Instead, the golden record should answer:
What is the authoritative representation of this business entity for the attributes governed by the master-data process?
For example:
Golden Customer
|
+-- Global Customer ID
+-- Legal Identity
+-- Standardized Address
+-- Hierarchy
+-- Classification
Salesforce may still own:
Sales Territory
Account Owner
Sales Stage
Relationship Status
The golden record and Salesforce record can coexist.
12. The Enterprise Customer ID Is More Important Than Salesforce Record ID
This is a practical architecture principle I strongly recommend.
Avoid making:
Salesforce Account.Id
the enterprise identity of the customer.
Instead, establish an enterprise identifier such as:
GlobalCustomerId
Then:
GlobalCustomerId
|
+----+----+
| | |
SFDC ERP MDM
Salesforce maintains its own Salesforce ID.
ERP maintains its own identifier.
MDM maintains its own identifier.
The enterprise identifier creates a cross-system identity relationship.
13. The Cross-Reference Model
A mature architecture may maintain:
| System | Identifier |
|---|---|
| MDM | MDM-100023 |
| Salesforce | 001XXXXXXXX |
| ERP | CUST-78452 |
| Legacy CRM | CRM-98213 |
All of these represent the same business entity.
Conceptually:
Global Customer ID
|
+---------------+---------------+
| | |
Salesforce ERP MDM
| | |
SFDC ID ERP ID MDM ID
This becomes essential in mergers, acquisitions, multi-org Salesforce strategies and legacy modernization.
14. Salesforce Multi-Org Makes Data Ownership Harder
This becomes even more important in a multi-org environment.
Imagine:
Global Customer
|
+-----+-----+-----+
| | |
Org A Org B Org C
US Europe APAC
Each Salesforce org may have its own:
Account ID
Contact ID
Account hierarchy
local attributes
Without enterprise identity management, the same customer can appear as three unrelated customers.
This is one reason org strategy and data architecture cannot be designed independently.
15. A Customer Can Exist in Multiple Salesforce Orgs
This does not necessarily mean data quality is broken.
For example:
Global Customer: CUST-1001
Salesforce US
Account ID: 001-US
Salesforce UK
Account ID: 001-UK
Salesforce APAC
Account ID: 001-APAC
The architecture should establish:
GlobalCustomerId = CUST-1001
as the enterprise identity.
The Salesforce IDs remain local identifiers.
This distinction becomes particularly important for:
- global account management
- customer 360
- reporting
- consent
- cross-region sales
- acquisitions
- enterprise analytics
16. The Data Ownership Triangle
One model I find useful when reviewing enterprise data architecture is what I call the Data Ownership Triangle.
Every important data element should answer three questions:
WHO OWNS IT?
/\
/ \
/ \
/ \
/ \
WHO CHANGES IT? ---- WHO CONSUMES IT?
These are not necessarily the same system.
For example:
Customer Credit Limit
Owner:
ERP
Changed by:
Finance users
Consumed by:
Salesforce
Commerce
Customer Portal
This is much clearer than saying:
“ERP is integrated with Salesforce.”
Integration tells us how systems communicate.
Ownership tells us why they communicate.
17. CRUD Ownership
A practical technique is to explicitly define CRUD authority.
For each data domain, ask:
| Operation | Salesforce | ERP | MDM |
|---|---|---|---|
| Create | No | No | Yes |
| Read | Yes | Yes | Yes |
| Update | Limited | Limited | Yes |
| Delete | No | No | Governed |
This prevents the dangerous situation where three systems believe they can update the same master record.
18. Read Access Does Not Imply Ownership
This sounds obvious but is frequently violated.
Suppose Salesforce displays:
Credit Limit = $500,000
That does not mean Salesforce owns the credit limit.
Salesforce may simply be consuming the value from ERP.
Conceptually:
ERP
|
| Credit Limit
v
Salesforce
|
v
Sales User
The Salesforce UI is the presentation point.
ERP remains the system of record.
This distinction should be explicit in architecture documentation.
19. Write-Back Is Where Architectures Get Into Trouble
A common requirement is:
“Users want to update the value from Salesforce.”
That does not automatically mean Salesforce should become the owner.
Instead:
Salesforce UI
|
| Request Change
v
ERP / MDM
|
| Validate
v
Authoritative Data
|
| Publish Update
v
Salesforce
Salesforce becomes the user experience while the authoritative system retains ownership.
This pattern is particularly useful for sensitive financial or regulated data.
20. Avoid Bidirectional Synchronization by Default
One of the strongest principles I use in integration architecture is:
Bidirectional synchronization should be an exception, not the default.
Consider:
Salesforce <------> ERP
This immediately raises questions:
- Which system wins?
- What if both change the record?
- Which timestamp is authoritative?
- What happens during network failure?
- How are conflicts resolved?
- What happens if updates arrive out of order?
A unidirectional ownership model is usually easier:
ERP
|
| Master Data
v
Salesforce
Or:
Salesforce
|
| Sales Data
v
ERP
Bidirectional flows should exist only when there is a clearly defined reason and conflict strategy.
21. The “Last Write Wins” Trap
A dangerous synchronization strategy is:
“The latest update wins.”
Imagine:
10:01 Salesforce → Address A
10:02 ERP → Address B
10:03 Salesforce → Address A
Which address is correct?
Time alone does not establish business authority.
A better architecture determines:
Address Owner = MDM
Then Salesforce and ERP consume the authoritative value.
The architecture becomes deterministic.
22. Data Quality Is an Architecture Responsibility
Data quality is often delegated to operations teams.
In reality, many data-quality problems are architectural.
Duplicate customers can be caused by:
- missing enterprise identifiers
- unclear ownership
- multiple systems creating customers
- inconsistent matching rules
- uncontrolled integrations
- regional Salesforce orgs
- manual imports
For example:
Salesforce
|
Create Customer
|
v
MDM
|
Match / Deduplicate
|
v
Golden Record
The architecture should prevent duplication rather than simply clean it up afterward.
23. MDM Should Not Become a Centralized Bottleneck
Another misconception is:
“If we implement MDM, every customer operation must go through MDM synchronously.”
That can create unnecessary coupling.
A better architecture might be:
MDM
|
Golden Customer Data
|
+---------+---------+
| |
Salesforce ERP
| |
Local usage Local usage
MDM governs the master.
Operational systems retain data needed for their own business processes.
Not every interaction requires a real-time round trip to the MDM platform.
24. Reference Data Is Different From Master Data
Architects should also distinguish:
Master Data
Business entities.
Customer
Product
Supplier
Reference Data
Controlled values used across systems.
Country
Currency
Industry
Customer Type
Order Status
Reference data often requires its own governance strategy.
If Salesforce uses:
Customer Type = Enterprise
while ERP uses:
CustomerType = ENT
the integration architecture needs a canonical mapping.
25. Canonical Models: Useful but Dangerous
Enterprise architecture sometimes introduces a canonical customer model:
Canonical Customer
|
+----+----+
| |
Salesforce ERP
This can reduce point-to-point transformations.
But canonical models can also become huge and difficult to evolve.
I prefer a canonical model only when there is a genuine enterprise need.
Do not create a canonical model simply because:
“Enterprise architecture should have one.”
The model must provide measurable architectural value.
26. The Data Flow Should Follow Ownership
Suppose MDM owns Customer Identity.
A clean architecture might be:
MDM
|
Customer Golden Record
|
+------+------+
| |
Salesforce ERP
| |
Engagement Finance
Salesforce should not independently modify the master identity and then ask MDM to reconcile it later unless the business process explicitly supports that model.
Ownership should determine the direction of data flow.
27. Ownership Determines Integration Direction
This is one of the most useful principles in data architecture:
The system that owns the data should generally be the producer of authoritative changes.
For example:
ERP owns Invoice
Then:
ERP → Salesforce
not:
Salesforce → ERP → Salesforce
Similarly:
Salesforce owns Opportunity
Then:
Salesforce → ERP
for downstream consumers.
The integration architecture becomes much easier to reason about.
28. Event-Driven Data Propagation
This is where data architecture connects directly with event-driven architecture.
If MDM owns customer identity:
MDM
|
| CustomerMasterUpdated
v
Event Infrastructure
|
+----> Salesforce
+----> ERP
+----> Data Platform
If Salesforce owns opportunity information:
Salesforce
|
| OpportunityWon
v
Event Infrastructure
|
+----> ERP
+----> Data Platform
+----> Notifications
Ownership determines the source.
Events determine how the change propagates.
29. APIs and Data Ownership
APIs are not just technical interfaces.
They can enforce ownership.
For example:
Salesforce
|
| Update Customer Address
v
MDM API
The MDM API can:
- validate
- match
- standardize
- authorize
- update
- publish the resulting change
Salesforce does not directly modify the master database.
This creates a clear ownership boundary.
30. Never Integrate Directly With Another System’s Database
This principle becomes even more important with master data.
Avoid:
Salesforce
|
| SQL
v
ERP Database
or:
Salesforce
|
| Direct DB update
v
MDM Database
The database is an implementation detail.
The system’s business interface should own the data.
Prefer:
Salesforce
|
v
API / Event
|
v
Authoritative System
This protects ownership and allows the system to evolve internally.
31. Golden Record vs Salesforce Record
It is useful to visualize them separately.
Golden Record
CUST-10001
|
+-----------+-----------+
| |
Salesforce ERP
001XYZ C-7821
| |
Sales Relationship Finance
The Salesforce record is not necessarily a duplicate of the golden record.
It is a domain-specific representation of the customer.
This is a much healthier enterprise data model.
32. Customer 360 Is Not the Same as Master Data
Another common misconception:
“Customer 360 means Salesforce should own everything about the customer.”
Not necessarily.
Customer 360 is primarily about creating a unified view.
It can aggregate:
CRM
ERP
Commerce
Support
Marketing
Data Lake
MDM
A 360 view may therefore be:
Customer 360
|
+--------------+--------------+
| | | | |
CRM ERP Commerce Support MDM
The 360 view does not automatically change data ownership.
33. Data Architecture for AI Makes Ownership Even More Important
This becomes increasingly important as enterprises introduce AI agents.
An AI agent may ask:
“What is this customer’s current credit limit?”
Where should the answer come from?
Not necessarily Salesforce.
The architecture should know:
Credit Limit
|
v
ERP
|
v
Authoritative Value
AI systems make data ownership more important because they can consume information from many enterprise sources.
An AI architecture built on ambiguous ownership can produce confident but incorrect answers.
34. Data Ownership and AI Agents
Consider an enterprise agent:
AI Agent
|
+--> Salesforce
+--> ERP
+--> MDM
+--> Data Platform
If all systems contain:
Customer Address
the agent needs to know:
Which system is authoritative?
That information should come from the enterprise data architecture, not from the AI model guessing.
This is one reason I believe data ownership will become even more important in agentic enterprise architecture.
35. Data Lineage
Once data moves between systems, architects should be able to answer:
Where did this value originate?
For example:
Customer Address
|
v
MDM
|
v
Integration Layer
|
v
Salesforce
|
v
Data Platform
|
v
AI Agent
If the AI produces:
“The customer address is Amsterdam.”
the organization should ideally know:
Source → MDM
Last Updated → timestamp
Propagated Through → integration pipeline
Consumed By → AI
Data lineage becomes increasingly important as enterprise architectures become more distributed.
36. Data Ownership During Mergers and Acquisitions
This is one area where data architecture becomes especially challenging.
Imagine an organization acquires another company.
Before acquisition:
Company A
Salesforce A
ERP A
MDM A
Company B:
Salesforce B
ERP B
MDM B
After acquisition:
Enterprise
|
+---- Salesforce
+---- ERP
+---- MDM
The hardest problem may not be migrating records.
It may be deciding:
Which organization owns the customer identity going forward?
A migration project without an ownership strategy simply moves the duplication problem into the new architecture.
37. Data Ownership in Salesforce Org Consolidation
Similarly, when consolidating Salesforce orgs:
Org A
Org B
Org C
|
v
Target Org
do not start with:
“How do we migrate the Accounts?”
Start with:
- Which customers are duplicates?
- Which org owns each relationship?
- What is the enterprise customer identity?
- Which attributes are authoritative?
- Which history must be preserved?
- Which system owns the resulting record?
Data migration should follow the target architecture.
Not the other way around.
38. A Practical Enterprise Data Architecture
A pattern I frequently recommend is:
Enterprise Identity / MDM
|
Golden Customer
|
+-------------+-------------+
| |
Salesforce ERP
| |
Customer Engagement Finance Operations
| |
+-------------+-------------+
|
Integration Layer
|
+----------+----------+
| | |
Data Analytics AI
Platform
Each system performs the role it is best suited for.
No system needs to own everything.
39. The “One Source of Truth” Principle Needs Refinement
The phrase:
“One source of truth.”
sounds architecturally attractive.
But in a complex enterprise, it can become misleading.
A better principle is:
One authoritative owner for each business data domain or attribute.
There may be multiple authoritative systems across the enterprise.
For example:
Customer Identity → MDM
Opportunity → Salesforce
Invoice → ERP
Product → Product Master
Employee → HR
This is more realistic than forcing everything into one master system.
40. The Data Authority Map
For every major enterprise entity, I recommend creating a Data Authority Map.
Example:
CUSTOMER
Identity
Owner: MDM
Financial
Owner: ERP
Relationship
Owner: Salesforce
Marketing
Owner: Marketing Platform
Consent
Owner: Consent Platform
Analytics
Consumer: Data Platform
This becomes a foundational architecture artifact.
It should exist before large-scale integration development begins.
41. A Data Ownership Decision Framework
When deciding ownership, ask:
1. Which system has the business responsibility?
Who is accountable for the correctness of the data?
2. Where is the business process managed?
Which system actually governs the process?
3. Who validates the data?
Where are the business rules enforced?
4. Who can legally or operationally modify it?
This is particularly important for regulated information.
5. Who consumes it?
Understanding consumers helps determine distribution requirements.
6. What happens if the system is unavailable?
This exposes whether the data is truly authoritative or merely cached.
42. The Five Questions I Ask in a Data Architecture Review
When I review a Salesforce integration landscape, I find these five questions particularly useful:
Question 1
Who owns this data?
Question 2
Who is allowed to change it?
Question 3
Who needs to consume it?
Question 4
What identifier connects the records across systems?
Question 5
What happens when two systems disagree?
If the architecture team cannot answer these questions, I would not rush into building the integration.
The integration design is not mature yet.
43. A Simple Conflict Resolution Model
Suppose:
Salesforce → Customer Address A
ERP → Customer Address B
MDM → Customer Address C
Do not immediately build reconciliation logic.
First determine:
Address Owner = MDM
Then:
MDM
|
| Authoritative Address C
+------------+
|
+------+------+
| |
Salesforce ERP
The conflict disappears because authority has been established.
This is one of the biggest benefits of proper data governance.
44. Architecture Anti-Pattern: The Integration Spider Web
One of the clearest signs of poor data ownership is a spider-web integration architecture.
Salesforce
/ | \
/ | \
ERP MDM Legacy
\ | /
\ | /
Marketing
Every system talks to every other system.
This often happens because ownership was never established.
A healthier architecture has clear authority boundaries:
MDM
|
+------+------+
| |
Salesforce ERP
| |
+------+------+
|
Consumers
The objective is not necessarily fewer integrations.
The objective is clearer responsibility.
45. Architecture Anti-Pattern: Salesforce as the Universal Master
Salesforce is an extremely capable platform.
That does not mean it should become the master for:
- customer identity
- products
- pricing
- invoices
- payments
- employees
- suppliers
- legal entities
unless the business architecture explicitly determines that Salesforce is the appropriate owner.
Technology capability should not determine data ownership.
Business responsibility should.
46. Architecture Anti-Pattern: MDM for Everything
The reverse is also dangerous.
Not every Salesforce object needs to become an MDM entity.
For example:
Opportunity
Case
Task
Campaign Member
may be naturally owned by Salesforce.
Trying to centralize every piece of enterprise data in MDM creates:
- unnecessary complexity
- synchronization overhead
- governance burden
- latency
- additional infrastructure
MDM should focus on data that genuinely requires enterprise master-data governance.
47. Architecture Anti-Pattern: Golden Record as a Reporting Database
A golden record should not simply become another reporting store.
Its purpose is to establish governed identity and authoritative master data.
Analytics platforms may consume the golden record:
MDM
|
v
Data Platform
|
v
Analytics
But the analytical representation does not automatically become the master.
Again:
Consumption does not equal ownership.
48. Data Architecture and Integration Architecture Must Be Designed Together
I strongly believe these two architecture disciplines should not be separated.
Data architecture answers:
Who owns what?
Integration architecture answers:
How does the data move?
If ownership is wrong, even a technically excellent integration architecture will create long-term problems.
The correct sequence is often:
Business Domain
|
v
Data Ownership
|
v
System of Record
|
v
Data Contract
|
v
Integration Pattern
|
v
API / Event / CDC
This is a much stronger architecture process than starting with:
“Which Salesforce API should we use?”
49. A Complete Salesforce Enterprise Data Flow
Putting everything together:
Business Domains
|
+--------------+--------------+
| | |
Customer Sales Finance
| | |
v v v
MDM Salesforce ERP
| | |
+--------------+--------------+
|
Integration Layer
|
+-------------+-------------+
| | |
Events APIs CDC
| | |
+-------------+-------------+
|
Data Platform
|
+------+------+
| |
Analytics AI
The architecture becomes easier to scale because every major data flow has a reason.
50. My Practical Rule: Ownership Before Integration
If I had to reduce this entire topic to one architecture rule, it would be:
Never design the integration before deciding who owns the data.
Because once ownership is clear, many other decisions become easier.
Ownership tells us:
- who creates it
- who updates it
- who validates it
- where it is stored
- which system publishes changes
- which systems consume changes
- how conflicts are resolved
- where the golden record lives
Then we can choose:
- API
- Platform Event
- CDC
- batch
- replication
- middleware
- data platform
based on the actual requirement.
51. The Salesforce Architect’s Data Architecture Checklist
Before approving an enterprise Salesforce data architecture, I would want clear answers to all of these:
- What are the enterprise master-data domains?
- Who owns each domain?
- Which attributes have different owners?
- What is the system of record?
- What is the system of engagement?
- What is the system of reference?
- Is there an enterprise identifier?
- How are duplicates resolved?
- Where is the golden record maintained?
- Who is allowed to create the entity?
- Who is allowed to update it?
- Is bidirectional synchronization really necessary?
- How are conflicts resolved?
- What is the authoritative source for each attribute?
- How are changes propagated?
- Are APIs or events more appropriate?
- How is data lineage maintained?
- How is data quality measured?
- How is master data governed?
- How does the architecture handle multiple Salesforce orgs?
- How does the architecture handle acquisitions?
- How will AI consumers identify authoritative data?
52. Final Architecture Perspective
After working across large enterprise application and integration landscapes, one lesson has become increasingly clear to me:
Most enterprise data problems are not caused by the absence of data. They are caused by too many systems believing they own the same data.
Salesforce can be the right system of record for some business domains.
It can be a system of engagement for others.
It can be a consumer of master data for others.
And it can participate in an enterprise-wide data ecosystem without owning the enterprise’s entire customer universe.
The architecture becomes much cleaner when we explicitly separate:
Ownership
↓
Authority
↓
Identity
↓
Golden Record
↓
Distribution
↓
Consumption
The objective is not to make Salesforce the master of everything.
The objective is to make every important piece of enterprise data have a clear authority.
That is what makes an enterprise Salesforce data architecture scalable.
The Architect’s Principle
I use this as a simple test when evaluating data architecture:
If two systems can independently change the same business attribute, ask who actually owns it.
If the answer is:
“Both.”
then the next question should be:
“Why?”
Sometimes there is a legitimate business reason.
Most of the time, it is an architecture decision that was never explicitly made.
And that is where many integration problems begin.
A scalable Salesforce architecture therefore starts not with objects, APIs, middleware or databases.
It starts with a much more fundamental question:
Who owns the truth?
Once that is clear, the rest of the architecture has something solid to build upon.