Salesforce as Source of Truth: Data Governance Implications

What Source of Truth Actually Requires

A system of record (SoR) or source of truth for a data domain means three things simultaneously: it is the system where authoritative changes are made (writes go here first), it is the system that other systems synchronise from (other systems are downstream consumers), and it is the system that wins in a conflict (if SAP and Salesforce disagree on a customer's address, Salesforce's version is correct). All three requirements must hold for the designation to be architecturally meaningful.

Many organisations declare Salesforce the system of record without implementing any of these three requirements consistently. Updates still happen in the ERP and sync to Salesforce (bidirectional sync without authority). Downstream systems occasionally override Salesforce data without notification (no conflict resolution policy). And when disputes arise about which system has the correct data, there is no defined escalation path. The declaration is aspirational rather than architectural.

The technical implementation of source-of-truth status requires: preventing authoritative changes in competing systems (access controls or API restrictions that prevent other systems from writing to data domains owned by Salesforce), propagation mechanisms that push Salesforce changes downstream (CDC, Platform Events, ETL outbound from Salesforce), and conflict detection monitoring that alerts when a downstream system's version diverges from Salesforce's version.

Data Domain Boundaries for Salesforce Ownership

Salesforce is naturally authoritative for data domains that are managed through Salesforce-native processes: customer relationship data (Account hierarchy, contact details, relationship history), sales pipeline data (Opportunities, Quotes, Forecasts), and service data (Cases, Entitlements, Service history). These are domains where the business process that creates and updates the data runs inside Salesforce, making Salesforce the natural owner.

Salesforce is poorly positioned as the source of truth for financial transactional data (invoices, payments, general ledger entries), inventory data (stock levels, warehouse locations), order fulfillment data (shipping status, carrier tracking), and HR data (employee records, organisational charts). These data domains are created and updated by systems specifically designed for those purposes (ERP, WMS, TMS, HRIS), and making Salesforce authoritative for them would require re-routing all business processes through Salesforce — an impractical and expensive architectural change.

The practical governance decision for each data field is: who creates this field's value, and who updates it during the normal course of business? If the answer is "Salesforce users via Salesforce processes," Salesforce should own it. If the answer is "an ERP process," the ERP should own it and Salesforce should be a read-only consumer. Mixed answers (the field is created in one system and updated in multiple) indicate a data domain boundary dispute that requires an explicit governance decision, not a technology decision.

Write-Through vs Write-Back Integration Patterns

Write-through means a change to a data domain in Salesforce is immediately propagated downstream to all consuming systems before the operation is considered complete. The user's save action in Salesforce triggers a synchronous callout to the downstream system, and if the downstream write fails, the Salesforce write fails or is rolled back. This is the highest-consistency pattern — all systems are updated atomically — but it makes Salesforce's availability dependent on the downstream system's availability.

Write-back means Salesforce writes its data, and the downstream synchronisation happens asynchronously afterward. The user's save succeeds immediately in Salesforce; the downstream system is updated minutes or hours later. This is the most common pattern and provides the best user experience (no waiting for downstream systems), but it creates a window of inconsistency between Salesforce and downstream systems. Downstream systems that read data during this window see stale data.

The governance implication of write-back is that Salesforce must own conflict resolution logic. If SAP updates a customer's billing address during the write-back window (before the Salesforce change has propagated), whose change wins? The governance policy must define this explicitly: "Salesforce writes are authoritative — a Salesforce change always overwrites a downstream change made after the Salesforce change was committed" or "last-write-wins" or "SAP wins for billing-related fields, Salesforce wins for customer contact fields." Without this policy, the conflict resolution is undefined and inconsistency accumulates silently.

-- Monitoring for Salesforce-vs-ERP data conflicts
-- Run periodically to detect address divergence
SELECT sf.AccountId, sf.SFBillingStreet, sf.SFBillingCity,
       erp.ERPBillingStreet, erp.ERPBillingCity,
       sf.SFLastModified, erp.ERPLastModified
FROM salesforce_accounts sf
JOIN erp_customers erp ON sf.SAP_Customer_ID = erp.KUNNR
WHERE sf.SFBillingStreet != erp.ERPBillingStreet
   OR sf.SFBillingCity != erp.ERPBillingCity
ORDER BY sf.SFLastModified DESC;
-- Alert when row count exceeds threshold

Privacy Regulations and Salesforce as Data Custodian

When Salesforce is the source of truth for customer data, it becomes the data custodian responsible for responding to data subject rights under GDPR (EU), CCPA (California), and equivalent privacy regulations. A customer's right to erasure (GDPR Article 17) — the "right to be forgotten" — requires that their personal data be deleted from all systems where it is held. If Salesforce is the source of truth for customer data, the erasure process must include Salesforce, and the erasure must propagate to all downstream systems that received the data from Salesforce.

Salesforce provides native tools for privacy compliance: the Individual object for tracking consent preferences, the Privacy Center tool (a managed package) for automated data subject request (DSR) processing, and field-level encryption via Shield for masking PII in the database. But these tools address the Salesforce org itself. They do not automatically propagate deletion or anonymisation to data warehouses, analytics platforms, or operational systems that received Salesforce data via ETL. The architecture of data distribution creates the architecture of deletion obligation.

Data lineage — tracking which systems received which data from Salesforce and when — is the prerequisite for comprehensive privacy compliance. Without lineage, when a deletion request arrives, the organisation cannot confidently identify all systems that hold copies of the data subject's information. Implementing data lineage as a governance capability (not just a compliance response) is a strategic investment for organisations where Salesforce is a significant data distribution hub.

Organisational Requirements: Policy and Accountability

The governance requirements for Salesforce as a source of truth are organisational as much as technical. Three organisational structures are required: a data stewardship team that owns the quality of Salesforce master data and resolves conflicts when they arise, a change management process that requires all downstream integration owners to be notified when Salesforce data structure changes (field additions, field name changes, object restructuring), and a clear escalation path when two systems disagree on a data value that no automation can resolve.

The most common governance failure is the absence of escalation. When Salesforce shows a customer's annual revenue as $50M and SAP shows $75M, and neither system has an audit trail for which value was correct, there is no automated resolution — a human with business context must make the call. If no human has the authority or the mandate to make that call, the conflict persists indefinitely, both systems diverge further, and reports from different systems show different numbers for the same customer. The data governance escalation path must be defined, documented, and exercised.