The Hidden Problem in Salesforce Implementations
Have you ever worked on a Salesforce implementation where the same business information is stored across multiple objects? A customer’s address exists on Account, Case, and an application object. Banking information is captured in an OmniScript and again through a service request. Former names are collected during registration, claim submission, and other business processes.Each implementation makes sense when viewed independently.
The administrator or developer building the Case process needs somewhere to store the information, so they create a few custom fields. Another team building an OmniScript captures similar information in a different object. Eventually, a third process needs that same information. Before long, the organization has multiple versions of the same business information.
Which object contains the correct information? More importantly, which object should downstream processes trust? This is where I believe architects need to shift their thinking. The question should not be, “Where should I create these fields?” It should be: What business entity does this information belong to, and where should its authoritative version be maintained?” This distinction becomes increasingly important as Salesforce implementations grow and business processes evolve.
I recently encountered this challenge while designing a claims management solution on Salesforce Public Sector Solutions. Two seemingly unrelated requirements—capturing claimant banking information and maintaining former names—raised the same underlying architectural question. How do we maintain one authoritative source of information when different business processes capture and update that information? That experience led me to develop the MASTER Framework.
2. Recognizing When You Need a System of Record
Before selecting an object, architects should first recognize when authoritative data ownership needs to be explicitly defined. One warning sign is when the same business information starts appearing across multiple objects. For example, consider a claims management application with two business processes.
Business Process 1: Initial Claim Submission
A claimant completes a 40-step OmniScript wizard. As part of the claim submission, the claimant provides banking information that will eventually be used to make compensation payments.
Business Process 2: Change of Representation
A claimant who was previously represented by a business entity decides to represent themselves. This change is handled through a Case with a specific record type. The process also captures the claimant’s banking information because future payments may need to be made directly to the claimant. Both business processes capture payment information.
Should the OmniScript maintain the banking information? Should the Case become the source of truth? Should both objects maintain independent copies? In our architecture, we identified Claim Participant as the authoritative business owner of payment information. Why? Because the payment information belongs to the claimant’s participation in a particular claim. The OmniScript and Case are simply different entry points through which that information is captured. The entry point does not determine the system of record.
When should architects establish a master object?
My recommendation is to look for three signals:
- Shared business entities: The same type of information is captured or maintained across multiple business processes.
- Competing authoritative values: Different objects could independently claim to contain the current, correct information.
- Future business capabilities: Centralized information could support identity resolution, deduplication, analytics, fraud detection, or additional processes.
However, duplication alone does not automatically justify creating another object. An application may legitimately preserve the address provided at submission, while a customer record maintains the current residential address. The important question is whether these records represent separate business facts or competing versions of the same authoritative fact. That is the starting point for designing a system of record.
3. Introducing the MASTER Framework
I use six architectural decisions to approach this problem.
M — Model the Entity
A — Assign Authority
S — Standardize Updates
T — Track History
E — Establish Identity
R — Retain Transactional Truth
The objective is not to create more Salesforce objects. It is to establish a consistent approach to data ownership, maintenance, identity, and consumption.
M — Model the Entity, Not the Form
One of the first questions I ask when designing a data model is whether the information represents a one-to-one or one-to-many relationship. Consider former names. A claimant may have multiple former names over their lifetime. From a business perspective, that is a one-to-many relationship. A dedicated Former Name object related to the claimant makes sense. Now imagine another business process captures only one former name through a Case. It might be tempting to create a Former Name field directly on Case. I would challenge that design. Just because a particular form captures only one former name does not mean the underlying business relationship has changed. The organization already has a Former Name entity. The new process should populate that entity rather than introduce another independent representation. This also supports future requirements. Former names can become valuable when identifying duplicate claimants, matching historical records, or investigating potentially inconsistent identity information.
The same thinking applies to addresses. A claimant may have residential, mailing, and temporary addresses. Rather than scattering address information across unrelated objects, I would evaluate a consistent Address entity with address types and appropriate relationships.This creates opportunities for historical analysis, identity matching, and future predictive capabilities. Of course, before introducing custom objects, architects should evaluate whether Salesforce’s existing standard data model supports the requirement.
Architectural principle: Design around the true business entity and its relationships, not the limitations of the screen capturing the information.
A — Assign Authority Based on Business Context
A common mistake in person-centric architectures is assuming every piece of information about a person belongs at the person level. That is not necessarily true. Consider banking information. A claimant may participate in two separate claims, Claim A and Claim B. The claimant could use Bank Account A for the first claim and Bank Account B for the second. If banking information were mastered only at the Person Account level, changing the banking information for one claim could unintentionally affect the other. In our design, payment information is claim-specific. Claim Participant establishes the appropriate ownership boundary because it represents the claimant’s relationship to a particular claim.
A representation-change Case associated with Claim A should update only the appropriate Claim Participant for Claim A. Claim B remains unaffected. This introduces an important distinction: Person-centric architecture does not mean person-level ownership of every attribute.
The business context determines whether information belongs to a person, transaction, claim, or relationship. Architects must also distinguish logical ownership from physical storage. Claim Participant can be the authoritative business owner while sensitive banking information is physically maintained in a secured, versioned payment-instructions record associated with that participant.
Architectural principle: Assign authoritative ownership according to the business context in which the information is valid.
S — Standardize Updates Through a Centralized Service
Once the authoritative object has been identified, the next question is how multiple business processes should maintain it. My preference is to centralize authoritative data maintenance rather than create independent update logic for every entry point.
For example:
- The initial claim OmniScript captures banking information.
- A representation-change Case captures updated banking information.
- A future self-service process may allow claimants to update payment instructions.
Each process may have a different user experience and approval lifecycle. However, they should use a common service to maintain authoritative payment information. Depending on the implementation, that service could be built using Salesforce Flow or Apex. The service should consistently handle record identification, validation, duplicate prevention, authorization, and insert/update operations. There is another important consideration.
Capturing information does not automatically make it authoritative. In our representation-change scenario, the Case may capture new banking information before the representation change is approved. The proposed information should remain part of the pending transaction until the appropriate business conditions have been satisfied. Once approved, the centralized service can apply the authorized change to the relevant Claim Participant payment information. This avoids treating every submitted value as immediately trustworthy. The service should also protect against repeated requests, conflicting updates, and partial failures.
Architectural principle: Centralize authoritative data changes, not necessarily the business processes that initiate them.
T — Track Business History, Not Just Field Changes
Another decision architects need to make is whether authoritative information should be overwritten or preserved historically. Consider a claimant’s residential address. The claimant initially lives at Address A. Six months later, the claimant moves to Address B. If we simply overwrite the existing address, we lose an easily reportable representation of the previous address. Salesforce Field History Tracking can help us understand changes to tracked fields, but it is not always the most practical mechanism for business reporting or historical analysis.
My preference, when the business needs historical state, is to use effective-dated records. For example:
| Address | Effective Start | Effective End | Status |
|---|---|---|---|
| Address A | January 1 | June 30 | Historical |
| Address B | July 1 | — | Current |
When the address changes, the centralized service closes the previous effective period and creates a new record. This allows the business to answer questions such as:
- What was the claimant’s residential address at the time of claim submission?
- How many times has the claimant changed addresses?
- Are multiple claimants associated with the same historical address?
- Were particular addresses shared during overlapping periods?
These capabilities may become valuable for reporting, identity analysis, and fraud investigations. I would still use Field History Tracking as a complementary auditing mechanism to record tracked field-level changes, subject to Salesforce’s retention and configuration limits. The design must also prevent unintended overlapping effective periods and distinguish the date a change was recorded from the date it became valid when those dates differ.
Architectural principle: Preserve business history when the organization needs to understand what was true at a particular point in time.
E — Establish Identity Before Associating Records
Centralizing data does not automatically prevent duplicates. Consider a claimant who provides a former name during initial claim submission. Several months later, another business process captures the same former name. How should the system determine whether the information belongs to an existing claimant and whether a new Former Name record is necessary?
I would approach this using two matching strategies. Exact matching: Use trusted, sufficiently unique identifiers, such as a verified government-issued identifier or an established internal claimant identifier, to identify an existing person. An exact value match should not automatically be considered conclusive if the identifier is unverified or inconsistent with other evidence. Likelihood-based matching: When reliable unique identifiers are unavailable, evaluate combinations of attributes such as date of birth, first name, last name, and former-name similarity. For example, a fuzzy name match combined with matching demographic information might suggest that two records represent the same person. However, a likely match is not necessarily an exact match. I would flag uncertain matches for human verification rather than automatically merge or associate records. Once the claimant has been identified, the service should separately determine whether the incoming former name already exists for that claimant.
This distinction is critical. Matching the person and matching the person’s former-name record are two different operations. Sensitive identity information must also be protected through appropriate access controls, secure processing, and data minimization.
Architectural principle: Establish identity using trusted evidence, and introduce human verification when automated matching cannot confidently resolve ambiguity.
R — Retain Transactional Truth
One of the more subtle architectural challenges occurs when authoritative information changes after a business transaction has already started. Consider payment processing. A claimant has approved banking information associated with Claim Participant. A payment transaction is initiated using that information. Later, the claimant changes their banking information through an approved business process. Should the existing payment transaction automatically use the new information? In our design, the answer is no.
The payment transaction preserves the payment instructions selected when the transaction was initiated. Meanwhile, the authoritative payment information can change for future payments. For example:
| Event | Authoritative Payment Information | Transaction |
|---|---|---|
| January | Bank Account A | No payment initiated |
| February | Bank Account A | Payment 1001 captures Account A |
| March | Bank Account B becomes current | Payment 1001 retains its original instructions |
| April | Bank Account B | Payment 1002 captures Account B |
This design protects transaction integrity. It also illustrates why a single source of truth does not necessarily mean there should be only one physical copy of information. The authoritative record answers: “What is the currently approved payment information?” The transaction snapshot answers: “What payment information was used for this particular payment?” Both can be correct because they represent different business facts.
For sensitive banking information, a transaction snapshot may contain a secured payment reference or token rather than duplicating complete bank account details.
Architectural principle: Master data represents authoritative business state; transactional snapshots preserve the state used to execute a specific business event.
4. Applying MASTER Across Salesforce Business Processes
Let’s bring the framework together using the three examples.
| Architectural dimension | Banking information | Former names | Addresses |
|---|---|---|---|
| Business entity | Payment instructions | Former name | Address |
| Ownership scope | Claim Participant | Person | Person or relevant business relationship |
| Multiple entry points | Claim OmniScript, representation-change Case | Claim form, personal representative process | Registration, Case, application |
| Cardinality | Potentially multiple versions per claim participant | One-to-many per person | One-to-many per person |
| Centralized maintenance | Shared payment-information service | Shared former-name maintenance service | Shared address maintenance service |
| Historical design | Effective-dated payment instructions | Former-name history as required | Effective-dated addresses |
| Identity considerations | Correct claim and participant | Person matching and duplicate names | Address matching and shared-location analysis |
| Transactional truth | Payment instruction snapshot | Identity information at submission, if required | Address at application submission, if required |
These examples demonstrate why system-of-record design is not simply a question of choosing between standard and custom objects. It is a question of establishing ownership, business relationships, change governance, and historical meaning.
5. Architectural Tradeoffs: What Should Architects Watch For?
While I favor centralized authoritative data management, there are tradeoffs architects must evaluate. Centralization versus coupling: A shared service reduces duplicated logic, but it should not become a large, tightly coupled component responsible for every downstream process. Keep authoritative data maintenance focused. Let downstream processes consume approved information through clear interfaces.
Reuse versus overengineering: A new business requirement does not automatically justify another custom object. Start with the existing enterprise data model and Salesforce standard capabilities. Introduce new objects when the entity’s relationships, lifecycle, security, or reporting requirements justify them.
Current truth versus historical truth: Some business information only needs its current value. Other information requires effective-dated history.Do not implement complex historical structures everywhere, but do not overwrite information that the business will later need to reconstruct.
Automation versus human judgment: Exact matching based on trusted identifiers can support automated association. Probabilistic matching introduces uncertainty. Human verification is appropriate when an incorrect association could create material business, financial, or compliance risk.
Data reuse versus data protection: Centralized access to sensitive information can improve consistency, but it also increases the importance of security design. Payment and identity information require careful consideration of field access, encryption, retention, masking, and integration boundaries.
6. The MASTER Architecture Decision Scorecard
Before approving a Salesforce data model involving shared business information, I recommend asking eight questions.
| # | Architecture review question |
|---|---|
| 1 | Does this information represent an existing business entity, even when captured through a different process? |
| 2 | Have we identified the true cardinality and relationships of the entity? |
| 3 | Is the information person-specific, transaction-specific, or relationship-specific? |
| 4 | Have we identified the authoritative owner and distinguished it from temporary capture records? |
| 5 | Do different entry points use consistent validation, approval, and update rules? |
| 6 | Have we defined exact matching, possible matches, and human verification where necessary? |
| 7 | Do we need effective-dated history, field-level auditing, or both? |
| 8 | Do downstream processes understand when to use current authoritative information versus a transactional snapshot? |
I would use this checklist during data-model reviews, architecture review boards, and solution design workshops. The objective is not to force every implementation into the same technical pattern. It is to ensure that the important architectural decisions have been made deliberately rather than emerging accidentally from individual development stories.
7. Final Thoughts: Design for the Entity, Not the Entry Point
In many Salesforce projects, data-model problems do not begin with a poor architectural decision. They begin with a series of reasonable local decisions.A developer adds a field to a Case because the Case needs it. Another team adds similar fields to a custom object because its OmniScript needs them. A third team creates another representation because its business process has slightly different requirements. Each solution works.But collectively, the organization loses clarity about where authoritative information lives.
My recommendation is to identify shared business entities early, establish their ownership boundaries, and create consistent mechanisms for maintaining them.
Use the MASTER Framework to ask:
- Are we modeling the actual business entity?
- Have we assigned the right authoritative owner?
- Are updates governed consistently?
- Can we reconstruct historical business state?
- Can we reliably identify the correct records?
- Are downstream transactions preserving the information they actually used?
These decisions become increasingly important as organizations introduce more automation, integrations, analytics, and AI capabilities. AI and predictive systems cannot reliably compensate for unclear data ownership or inconsistent entity relationships.
A well-designed system of record is not simply a place where data is stored. It is an architectural contract defining who owns the information, how it changes, and when the business can trust it. That is the foundation of a maintainable, scalable, and trustworthy Salesforce architecture. As always feel free to post your comments or email me at buyan@eigenx.com for any questions.
