Bringing it all together with data modeling – Understanding Salesforce sharing and security – Salesforce Certified Data Architect Study Guide

Bringing it all together with data modeling

We’ve covered a lot in this chapter, but now it is time to put the theory into practice and produce something tangible in the form of a data model. Now we know the OWDs we can set, the relationships between objects we can influence, and the owners of records, we can bring them together to produce a data model.

Throughout this book, any data model diagrams will be drawn to the following format (essentially an expanded legend from the example diagram in Chapter 1, Introducing the Salesforce Data Architect Journey):

Figure 2.8 – The format for diagramming Salesforce objects used throughout this book

Now we’ve looked at the data modeling format, let’s now look at a data modeling example.

Data modeling example and explanation

With our data modeling format now covered, let’s take a look at an example data model to show how much information we can glean from a single artifact. Here’s the example, which is similar to the one shared in Chapter 1, Introducing the Salesforce Data Architect Journey:

Figure 2.9 – Example data model

Let’s look at the data model and see what we can determine from it:

• There is a private OWD model in play, so only record owners of Account and Contact and roles higher up in the role hierarchy will be able to view and edit records (unless records are shared using one of the other methods explained in this chapter, such as manual sharing).

• The Sales Exec role is designated the owner of accounts and contacts, with Finance the owner of the Invoice__c custom object. However, we can see that the OWD for Invoice__c is set to Controlled by Parent, so Sales Exec folks that own account records will be able to view and edit Invoice__c records as well.

• The Invoice__c object has been designated LDV given the amount of data, so we’ll need to ensure that we consider data skew. In this instance, we have both account skew and ownership skew to think about, and therefore we should ensure that no account record is the parent of more than 10,000 Invoice__c records, and also no single person from the Finance department owns more than 10,000 Invoice__c records, otherwise performance issues (as explained in the Overcoming data skew section) may occur.

As I’m sure you’ll agree, there is a lot of information packed into a seemingly small diagram, but it can quickly be determined what the default data access looks like and the sharing implications of the relationships, and we also get early insight into any LDV implications.

When answering practice questions related to data access and its effect on other objects, try to visualize how the question could be represented in a diagram where it makes sense to do so in order to get to the right answer.

The Importance of the Data Model in the Certified Technical Architect (CTA) review board

Those of you who are looking to pursue the CTA review board will be required to produce a data model that’s similar in nature to what we will produce throughout this book. The data model is considered a core artifact of the review board, and as such it is important that you know how to quickly produce clear data model diagrams that convey the right level of information.