Different data models tell different stories. Understanding how to leverage different industry standard types of data models can help Salesforce Architects communicate the appropriate details to technical and non-technical audience members.
From conceptual models that tell the high-level story of how data fits together for business stakeholders to physical models that unpack granular, attribute-level information that developers need to configure objects and fields, each type of model has a purpose. In this article, we’ll discuss how conceptual, logical, and physical models tell a unique story, and how architects can improve solution documentation and communication through their usage.
Conceptual Models
The conceptual model is your first step in developing new objects and object relationships in Salesforce. Conceptual models are drafted during the discovery phase of work to generate a representation of the relevant conceptual entities and their relationships.
Conceptual models offer a simple, functional abstraction of the data and should be easily understood by business and other non-technical stakeholders. This type of model helps business and other non-technical stakeholders understand what is happening in the business.
When drafting conceptual models, remember that:
- Entity names should be functional; they don’t take names from Salesforce objects or introduce API Names.
- Record Types can be left as separate conceptual entities.
- Many-to-many relationships are left intact.
- Minor annotations (i.e. “Required”) are used instead of more complex data modeling notations.
- Conceptual models are platform agnostic.
Key Points
- Audience: Business stakeholders (i.e. Clients or Business Analysts).
- Level of detail: Low.
- Use to communicate: The functional relationships between conceptual entities.
Best Practices
- Name entities using business terminology, not Salesforce terminology (i.e. Organization instead of Account).
- Create models by functional area and have fewer than ten entities per model (i.e. Workshop Attendance Conceptual Model).
- Don’t use complex data modeling notations or platform-specific relationship types (i.e. Lookup vs. Master-Detail).
- Reduce complexity by preserving many-to-many relationships.
Logical Models
Logical models are your next step in the journey towards an implementable solution. Where conceptual entities are functional representations of the business (but don’t necessarily represent the reality of the database), logical models become more concrete. Logical models are typically drafted during the design phase, where the conceptual model needs to be translated into a Salesforce solution.
A logical model is an actual representation of object-level information, as it exists (or will exist) in Salesforce. Your logical model should be platform-specific, using Salesforce modelling notation and relationships. This type of model helps technical and quasi-technical stakeholders understand what is happening in the Salesforce database at a high level.
When drafting a logical model, remember that:
- Conceptual entities must be translated into Salesforce standard and custom objects.
- API Names should be introduced and referenced.
- Record Types should be indicated on objects where applicable.
- Junction objects are introduced to reconcile many-to-many relationships.
- Relationships are indicated using Salesforce terminology; however, more complex (platform-agnostic) data model notations are not used.
- The model is representative of an actual Salesforce schema.
Key Points
- Audience: Technical and quasi-technical team members (i.e. Technical Consultants, Admins, or Business Analysts).
- Level of detail: Medium.
- Use to communicate: Object-level relationships, as they exist in Salesforce.
Best Practices
- Focus the model by functional area and have fewer than ten entities per model.
- Generate layered logical models where certain objects can be hidden to reduce complexity.
- Model actual Salesforce relationships (i.e. Lookup vs Master-Detail relationships).
- Include a legend.
You can also amplify the utility of your logical models even further by annotating your data models with key information like organization-wide defaults (OWDs), record owners, and data volumes.
Physical Models
While logical models provide a high-level representation of the actual model of the data in Salesforce, your physical model should go one step further by adding field-level detail. The most specific of the data models, you can think of the physical model as your detailed blueprint of the database.
This type of model helps technical stakeholders understand what is happening in the Salesforce database at a detailed level. These models are useful to draft during the design or implementation phase to help developers configure the solution in Salesforce. Physical models are useful design artefacts to support your team in configuring new functionality, as well as debugging existing functionality within Salesforce.
When drafting a physical model, remember that:
- Salesforce standard and custom object labels and API Names are referenced for clarity.
- All relevant objects, including junction objects (that reconcile many-to-many relationships), should be represented as they exist (or will exist) in the database.
- Fields and field types are introduced into the model.
- Relationships are indicated using traditional data model notation.
- The model is representative of an actual data model.
Key Points
- Audience: Technical stakeholders (i.e. Developers).
- Level of detail: High.
- Use to communicate: Field-level detail and platform-agnostic cardinality.
Best Practices
- Zoom in on the relevant part of the model (i.e. financial objects) to reduce the number of objects visible at one time.
- Annotate physical models with notes on automation or Validation Rules on the relevant object or field.
- Annotate physical models with field-level information such as PII/sensitive data flags, read-only fields, required fields, or fields with conditional visibility in the UI.
Final Thoughts
Remember that no data model is right or wrong – different data models simply tell different stories of the data!
Keep in mind these key takeaways:
- Conceptual models provide business stakeholders with a high-level, functional understanding of business data.
- Logical models provide quasi-technical stakeholders with a foundational understanding of the objects and their relationships in Salesforce.
- Physical models provide technical stakeholders with a detailed view of object and field-level data as it exists in the database.
As architects, our role is to ensure that our teams (composed of technical and non-technical stakeholders) can all understand the model of the data and how it supports the business. By selecting the appropriate data model for the job, we can give stakeholders the right information, pitched at the right degree of granularity, at the right time.
