Data Architecture
Not every customer fact belongs in Salesforce
A complete copy is not a complete customer view
Salesforce programmes often inherit an attractive but dangerous requirement: bring all customer data into CRM. It sounds like a route to a single customer view. In practice, copying everything can produce a second, slower version of the enterprise—one with unclear ownership, inconsistent refresh cycles, expanding storage, duplicated sensitive data and users who still do not know which value to trust.
A useful customer view contains the facts needed to make and execute customer decisions. It does not need every invoice line, web event, document revision and historical sensor reading. The architecture question is not whether Salesforce can hold a dataset. It is whether holding that dataset improves an operational journey enough to justify the cost, duplication and governance it introduces.
Start with decisions, not source tables
List the decisions Salesforce users and automations must make: approve a renewal, prioritise a service case, recommend an offer, confirm account risk or prepare an agent response. For each decision, identify the minimum facts, required freshness, acceptable latency, history depth, sensitivity and authoritative owner. This turns a vague data-unification ambition into a set of testable data products.
Then classify each fact by how it is used. Transactional fields that Salesforce owns belong in Salesforce. Small operational facts from another system may be replicated when local automation and resilience require them. Large or fast-changing datasets may be better summarised, federated or retrieved on demand. Old records needed only for audit or occasional investigation may belong in an archive with a controlled retrieval path.
Name one authority for every fact
A system of record is defined at the level of a business fact, not by declaring one application the master of the customer. Salesforce may own the account relationship status while an ERP owns credit terms, an identity platform owns login state and a data warehouse owns calculated lifetime value. The boundary should be explicit for each attribute and business event.
Record the authoritative source, permitted writers, update direction, conflict rule and expected freshness. If two systems can independently edit the same fact, the design needs a deterministic winner or a business-owned merge process. Timestamps alone are a weak conflict strategy because the latest change is not necessarily the most valid change. Ownership must follow accountability, not whichever integration ran last.
Replicate only when local behaviour needs it
Replication is justified when Salesforce must search, report, secure, automate or transact against the data without depending on a live remote call. A service entitlement used by case routing, for example, may need a small local representation even when the contract remains authoritative elsewhere. The replicated field should have a defined refresh mechanism, staleness indicator and recovery process.
Do not replicate a large source object merely because one screen needs three values. Move the smallest useful projection: an identifier, current status, relevant balance band or calculated risk indicator. This reduces reconciliation surface and protects users from irrelevant detail. It also keeps queries selective as volumes grow; Salesforce's Apex guidance emphasises selective SOQL because broad filters become increasingly costly on large datasets.
Virtualise data that must remain at its source
Salesforce's current architecture guidance describes data virtualisation as querying information at its authoritative source without copying it into Salesforce. Through patterns such as Salesforce Connect and supported federation capabilities, users can work with selected external data through Salesforce experiences while governance and residency remain with the source platform.
Virtualisation is a strong fit for large datasets, data with strict residency requirements and information that must be current at the moment of access. The trade-off is runtime dependency. Page performance, availability, query capability and security now depend on the remote system and connection. Use it for bounded interactions, define timeouts and degraded behaviour, and avoid designing a critical user journey that requires dozens of remote reads to assemble one screen.
Use Data 360 for unification without confusing ownership
Data 360 can ingest or federate data from Salesforce and external platforms, harmonise it into a common model and support identity resolution, calculated insights and activation. That is valuable when the business needs a cross-source customer profile for analytics, segmentation, personalisation or agent context. It does not remove the need to identify the authoritative system behind each input.
Treat the unified profile as a governed view assembled for defined uses, not a new place where every team can casually correct source data. Document lineage, match rules, consent, refresh timing and activation destinations. If a calculated insight is written back to CRM, label its meaning and timestamp so users understand that it is derived and may change when upstream data or identity resolution changes.
Design deletion and history before loading
Every replicated dataset creates another retention obligation. Define how long operational detail remains useful, when it becomes historical, where it is archived and how deletion or legal holds propagate. An archive is not a forgotten export file. It needs ownership, access controls, integrity checks, search or restoration procedures and evidence that policy is actually being executed.
Separate current operational state from immutable history. Users may need a two-year order summary in Salesforce but only occasional access to ten years of line-level transactions. Store the summary locally, retrieve detailed history through a deliberate path and keep the authoritative records where lifecycle controls are strongest. This keeps the CRM focused without sacrificing auditability.
Govern the data placement decision
For each new dataset, require a short placement record: business decision supported, authoritative owner, consumers, volume and growth, freshness, access pattern, sensitivity, retention, integration method, failure behaviour and reconciliation control. Compare four options explicitly—store, replicate a projection, virtualise, or archive—and record why the selected option is preferable.
Review the choice when volumes, regulations or user journeys change. A small replicated table can become a large-data-volume problem; a fragile live lookup can become a critical dependency; a once-useful field can become stale clutter. Data placement is an architectural decision with a lifecycle, not a one-time mapping exercise completed during migration.
The JSBC Labs view
Salesforce should contain the customer data that enables Salesforce to do its job well. Begin with operational decisions, assign authority fact by fact, replicate only the minimum required projection, virtualise data that belongs elsewhere, and use unified profiles for governed insight rather than indiscriminate duplication. Archive history with the same discipline used to load it.
The best customer view is not the biggest one. It is the view whose meaning, freshness and ownership can be explained to the person making a decision. When those qualities are designed first, Salesforce becomes a trusted operating platform instead of another destination for data the organisation has not learned to govern.