How to Validate Your Salesforce Data Model: A Step-by-Step Guide

A coherent data model forms the blueprint of your Salesforce solution design. When introducing new functionality to Salesforce, your data model forms the scaffolding of this design, against which all other decisions become contingent.

As such, designing and validating your data model is an essential step in the Discovery process. Approaching this process with a simple, approachable, plain-language framework can support developing and validating a strong conceptual model of the data.

Establishing a foundational data model (that is representative of the business and can later be translated into a technical solution) requires certain ingredients. I call these ingredients the “business rules”. I conceptualize business rules across two dimensions:

1. Key entities and their relationships.
2. High-level data ownership and visibility patterns.

In this article, I’ll share how functional architects and business analysts can elicit “business rules” to design and validate a coherent conceptual data model that lays the groundwork for useful, well-architected Salesforce solutions. 

Discovering Key Entities

First things first – establishing the major entities that will become objects in your Salesforce solution. In early project phases, entities are just things: People, Sales, Projects, Work items, or any thing that the business interacts with.

When beginning the conversation with a client or business stakeholder about the entities they work with, keep your language functional. You may ask questions like:

• How does your business accomplish [XYZ task or process]?

Open-ended questions like these will lead business stakeholders to begin disclosing the nascent conceptual entities that will be built into your model. They might respond with something like:

• At [ABC org], we work with Donor Organizations and Implementing Partners to run workshops. We deliver workshops over a few sessions and try to gather feedback from attendees so we can improve the workshops over time.

Already, we can begin to see certain conceptual entities arise:

• Donor organizations.
• Implementing partners.
• Workshops.
• Workshop sessions.
• Attendees.
• Feedback.

Architects are likely reading this list and immediately creating a mental association between entities like Donor Organizations and Implementing Partners with Accounts and Attendees with Contacts. At this stage, we’re not mapping conceptual entities onto Salesforce objects yet; keep conceptual entities in the business’s functional language to avoid assuming a technical solution before you understand the business thoroughly. 

Tip: Conceptual models are often the first type of data model drafted during the Discovery phase; learn more about how different data models can tell different stories about your data.

Validating Entity Relationships

Once a comprehensive list of conceptual entities is developed, you’ll need to identify and validate their relationships. This means identifying:

• Parent-child (1:M) relationships.
• Many-to-many relationships.

As a functional Solutions Architect or Business Analyst, you can likely infer certain entity relationships; however, it’s critical to validate these assumptions to ensure the utility of your technical design.

To validate relationships, you can ask questions like:

• Is it true that a workshop is funded by one donor organization? Can one donor organization fund many workshops over time?
• Is it true that a workshop must be delivered by a single Implementation Partner? Can one Implementation Partner deliver many workshops over time?
• Is it true that a workshop will be delivered over many sessions, but one session will only ever be related to one unique workshop?
• Is it true that one workshop session can have many attendees, and one attendee can attend many classes over time?
• Is it true that one attendee can give multiple points of feedback, but an instance of feedback is only ever sourced from a single attendee?

Any time the client says “no” (disagrees with your assumption), you need to dig deeper to establish the correct relationship. After some deliberation, you should be able to produce a conceptual entity with basic relationships.

As you move from conceptual design to technical solution, you will need to map conceptual entities onto Salesforce standard and custom objects and normalize the data model accordingly. For now, you may retain the functional nature of the data model so that it is approachable by business stakeholders. 

Determining Data Ownership

Now that you’re equipped with key entities and their relationships, we can begin to elicit the business’s data ownership rules. 

Record ownership drives various functions in Salesforce, including record visibility and deletion behaviour – as such, it’s important to understand which users would typically own and manage records of each object. Object permissions and record ownership in Salesforce can be a complex beast; remember to start high-level by determining basic patterns and then drill down into more nuanced requirements later on. 

Tip: The concept of “functional decomposition” states that one should start high-level and then drill down into more complexity. This can be a useful way to approach data visibility.

To elicit high-level ownership patterns, consider asking:

• Who would typically be responsible for creating and managing this data? Are there any notable exceptions to this rule?

The answers may look something like this:

Ideally, the owners you identify would align with functional personas that you have mapped out in your discovery process. 

Tip: Annotating your data model with record ownership patterns can increase the utility of your documentation. Learn more and access a template annotated data model here. 

Establishing Visibility Patterns

Now we know who owns and creates data, but what about the other users who need to interact with it? By establishing basic data visibility conventions and critical data visibility restrictions, we can continue to add color to our understanding of the business rules.

Visibility conventions will inform your Organization-Wide Defaults, whereas critical visibility restrictions will flag, at an early stage, any PII (Personally Identifiable Information) and/or sensitive data that requires special protection.

Consider the following line of questioning for each entity:

• Who generally has access to this data? Is it private to the record owner and a defined group they share it with, or can it generally be seen or edited by anyone in the org?
• Is there any data contained on this entity that is particularly sensitive and needs to be protected?

The answers may look something like this:

Remember that at this stage, we’re building a foundational understanding of the needs of the business that will require further development to generate a comprehensive technical solution.

Tip: Pre-built templates can help shrink the amount of time you spend on documenting your requirements. Check out these template business rules!

Summary

Establishing the basic rules of the business: what entities exist, how they are related, who owns data, and who sees data provides a comprehensive set of baseline functional information to begin building Salesforce solutions.

This information should be used during deeper discovery and design to ensure the consistency and correctness of all business requirements, ensuring that there are no discrepancies between your lower-level requirements (user stories) and your business rules.

For example, consider you have a business rule that states:

• One workshop can have many attendees, but one attendee can only participate in sessions for a single workshop over time.

But your user story states:

• As a Facilitator, I want to track all of the workshops an individual attends over time, so that I can report on their participation year over year.

The user story competes with the business rule, suggesting that one or the other is not true and requires revision to reach clarity on the requirement. These areas of contention arise in complex projects and are essential to resolve to ship robust solutions that add value to the business. By applying this “business rules” framework, you should be able to design and validate high-quality conceptual Salesforce data models.