The Architect’s Lens

One of the most valuable skills an architect brings to a project is not knowledge of Salesforce features. It is the ability to challenge assumptions. Recently, I was involved in a design discussion that initially appeared to be about Person Accounts, custom objects, and duplicate management. After digging deeper, I realized the real problem was something else entirely. The business and architecture teams were answering two different questions. ( Next step: Completed and ready to publish)

The Requirement

The organization manages claims. A claimant submits a claim and is identified using a unique identifier such as:

refore: Dependents should not be Person Accounts. At first glance, the logic sounds reasonable.

But architects should pause and ask a different question.

Reframing the Problem – Difference between Roles and Entities

Instead of asking: What information do we have today?

Ask: What entity are we modeling?

This is where the discussion shifted. The business was defining a person based on the information available at claim intake. Architecturally, we should define a person based on what they are, not based on how much information we currently know about them. A dependent without an SSN is still a person. The identity is incomplete. The person is not.

The Lifecycle Thinking Exercise

Architects should always think about what happens after the initial transaction. Imagine the following timeline.

The architecture team is now solving a migration problem that did not need to exist.

With a Person Account model:

Update Existing Person
Add SSN
Continue Lifecycle

No conversion. No migration. No redesign.

The Duplicate Myth

The Search Objection

One creates organizational learning. The other creates technical debt.

The Household Pattern

Most importantly, it aligns the data model with the real-world entity.

The Architect Takeaway

Here are 3 key takeaways from the blog for Architects.

1. Always design objects for entities not roles of the entity in a life cycle.
2. When dealing with business users, explain with analogies and do not use Salesforce acronmys like person accounts to solve problems.
3. Explain tradeoffs long term maintenance vs training with business value.or

If you have questions, feel free to post your comments or feel free to email me at buyan@eigenx.com.