Data Model Design Considerations When Building Salesforce Applications — Part 2
Part 1 of this series explored data model design considerations and best practices for Salesforce applications. While the topics covered in Part 1 apply to all Salesforce applications, including managed packages, there are few additional considerations that are specific to managed package applications. This post covers these additional considerations for first-generation (1GP) and second-generation (2GP) managed packages.
Understanding license dependencies
If your application has an object with a lookup or master-detail relationship to an object in Service Cloud (let’s say Entitlements), then your applications has a Service Cloud license dependency.
Here’s another example. If you create an object that has a reference to the managed package “Package A,” then your applications will have a dependency on “Package A”. In other words, your application installation will fail in a customer environment that does not have Package A.
One design pattern for designing applications without explicit license dependencies is creating a base package with custom objects and defining relationships between standard Salesforce objects and your base package objects in extension packages. The following diagram illustrates various packages and how their data model can be architected to avoid explicit license dependencies.
Let’s say you are designing an application that has a requirement to work for Salesforce organizations using B2B Commerce and those that do not have a B2B Commerce package (assume the organization will have only Service Cloud). In such a scenario, you would build your base package without any reference to objects from the B2B Commerce package and you would have a separate extension package in addition to the base package for B2B Commerce.
Here are some techniques for removing object dependency in your code to support customers with varying license types:
- Use custom metadata to allow customers to map objects and fields for business logic components.
- Write all your application code referencing custom metadata instead of objects.
- Create object-agnostic UI components. These components are designed with parameters that admins can configure to make the component work with any object.
Understanding the sharing implications of master-detail vs. lookup relationships
If you have a master-detail relationship between objects, the master (parent) record controls the detail (child) object records’ visibility. In other words, if your customer has different security needs for child objects than parent records, you are stuck.
As a rule of thumb, unless you are 100 percent sure that there won’t be any specific security requirements for child objects, use lookup relationships. The downside is you lose the ability to use rollup fields, but you can use platform security features that outweigh the downside of losing rollup fields. Also note that you cannot change these relationships once your application is packaged.
Understanding locked component attributes after a package is Managed — Released
It’s important to understand which components and attributes are locked after installation when a managed package moves to Managed — Released.
For example, consider a situation in which you chose to use a boolean field, and now want to change the field to a picklist. The problem is that the application is now installed in thousands of organizations! One way forward is to create the new field and modify all application logic to point to this field. The required application changes may sound simple but note that now you have data in thousands of organizations, so you’ll need to create a data script to transform the data. This is an example that shows how taking the time to make thoughtful decisions up-front can save many hours of work later.
Defining application boundaries
Keep in mind that the data model you create for the managed package can be extended and customized by application subscribers. Hence, it is essential to establish some documented boundaries and patterns for application subscribers. For example, document all the fields that are marked as external IDs on the objects. Provide flow templates that customers can clone and customize. Conduct user training with your application maintainers to explain Salesforce best practices for approaching business automation so they make best use of platform capabilities.
Refer to the following architect’s guides on automation best practices:
- Architect’s Guide to Building Forms on Salesforce
- Architect’s Guide to Record-Triggered Automation on Salesforce
What’s next?
For more on data model design considerations, be sure to read Part 1 of this series (if you haven’t already) and check out the following Trailhead modules:
About the author
Mohith Shrivastava works as a Developer Advocate at Salesforce. He currently holds Salesforce System and Application architect certifications. Mohith has a decade of experience architecting and building enterprise-scale products on Salesforce Customer 360 and the Salesforce Platform. You can follow him on his twitter handle @msrivastav13.
