The Short Answer
Source of Truth isn’t a technical question; it’s a question of authority: who within the organization is authorized to declare a particular value as correct. When this decision isn't made explicitly, it's made silently—by whoever wrote the last integration.
The core principle: ownership is determined at the field level, not the system level. The attempt to declare "the ERP is the source of truth for the customer" breaks the moment the Service department updates a phone number in Salesforce, and the nightly sync erases that update.
Three Questions That Determine Ownership
For each entity, and then for each group of fields, ask: where was the data first created, who is business-authorized to change it, and who bears responsibility when it's incorrect. In all three cases, the answer should be a job title, not a system name. The system is derived from the role.
When the answers point to two different roles, it's almost always a sign that two distinct fields have been compressed into one.
Example Ownership Matrix
| Entity / Field | Source of Truth | Salesforce | Sync Direction |
|---|---|---|---|
| Legal Name, Company ID, Payment Terms | ERP | Read-only | ERP ← Salesforce |
| Contact, Title, Preferences | Salesforce | Editable | Salesforce ← Marketing Systems |
| Product Catalog & Base Price List | ERP / PIM | Read-only | ERP ← Salesforce |
| Quote & Approved Discount | Salesforce | Editable | Salesforce ← ERP |
| Approved Order & Delivery Status | ERP | Read-only | ERP ← Salesforce |
| Outstanding Balance & Collection Status | Financial System | Read-only | Financial ← Salesforce |
| Activities, Cases, and Communication | Salesforce | Editable | No Outbound Sync |
This table is the deliverable. It's concise, it resides in a single document, and every new integration is vetted against it before being written.
Separating Presentation from Authority
Much of the tension between systems disappears when you understand that presenting data doesn't require copying it. An outstanding balance displayed to a salesperson doesn’t have to be a field in Salesforce that updates nightly; it can be a remote view or a federation layer.
Every copied field is an operational commitment: sync, failure, discrepancy, and time. Before copying, ask if automation or historical reporting is required on it. If not, it's better to present than to copy. An expansion on this approach can be found in Zero Copy and Federation in Data 360.
Conflicts: Decide in Advance, Not in Real-Time
Even when ownership is clear, situations of concurrent updates arise. Three possible rules: system precedence (the owner always wins), last timestamp, or flagging for manual intervention. The third rule is the safest for sensitive fields—provided there’s a processing queue with an owner, not just a sinking log entry.
Scenario: Organization with Two Truths for One Address
An infrastructure services company managed customer addresses in two systems: ERP for invoicing and a Field Service system for technician dispatches. Both were bi-directionally synced to Salesforce. The result: an address that flipped back and forth, and technicians arriving at a billing address.
The solution wasn't fixing the sync but decomposing the entity. Two separate fields were defined—billing address owned by the ERP, service address owned by the field system—both read-only in Salesforce, with a link to a change request routed to the correct owner. The number of service calls closed as "incorrect address" significantly decreased in the following quarter.
The lesson: when systems "fight" over a field, it often means two different business data points were given the same name.
Enforcement: From Document to Reality
An ownership matrix only exists if it’s enforced at three points: Field-Level Security that prevents editing on the non-owning side, an integration user with restricted permissions to only their owned fields, and a monthly report that shows fields updated contrary to policy. The third report reveals forgotten legacy integrations.
Documenting the meaning of each field directly connects to Data Mapping for Migration.
Common Risks and Preventive Actions
| Risk | How it Manifests in Practice | Preventive Action |
|---|---|---|
| System-level ownership | Contradictions within the same entity | Decision at the field or field group level |
| Bi-directional sync as default | Values intermittently flipping | One-way sync + read on the other side |
| Unnecessary copying | Dozens of synced fields without a consumer | Present instead of copying |
| Document without enforcement | Policy erodes within months | Field permissions + anomaly monitoring |
| No conflict queue | Discrepancies quietly accumulate | Processing queue with owner and SLA |
How to Measure Success
| Area | What to Measure | Check Frequency |
|---|---|---|
| Consistency | Discrepancy rate in key fields between systems | Monthly |
| Policy Violations | Writes to a field outside the defined owner | Monthly |
| Conflicts | Number and resolution time of items in queue | Weekly |
| Operational Impact | Incidents caused by incorrect data | Quarterly |
Building and enforcing an ownership matrix is carried out within our Integrations & Data service.
Source of Truth Decision Checklist
- ☐ List of key entities in the organization
- ☐ For each entity: where created, who is authorized, who is responsible for errors
- ☐ Ownership determined at the field or field group level
- ☐ Explicit sync direction for each group
- ☐ Every copied field stands the "it has a consumer" test
- ☐ Conflict resolution rule selected and documented
- ☐ Manual processing queue with owner and SLA exists
- ☐ Field-Level Security aligns with the matrix
- ☐ Integration user limited to owned fields
- ☐ Monthly report for policy violations
Professional Resources
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations & Data — https://hpi.pro/integrations-data