When building a database it’s so important to build the right relationships between database tables. What this means is that when we’re creating relationships between objects is that we’re deciding how they will be associated with one another. Salesforce has a very similar concept, which shouldn’t really be a surprise considering there’s a database powering the entire thing!

We can define the types of relationships between objects by creating custom relationship fields on objects. In this blog article, we’re going to talk about all of the custom relationships and how to build a really solid database schema.

Why Knowing About Salesforce Relationships Matters

The different types of data relationships determine how Salesforce will handle sharing, data deletions, and even required fields. And of course, my favourite is using formula fields to make things easier.

In some cases, we can’t easily undo the relationships that we create so it’s really important that we know why we’re doing things and what the outcome we’re looking for is.

Lookup Relationships

A lookup relationship loosely links two objects together which means they don’t necessarily depend on one another. The objects in the lookup relationship can have different sharing and security settings which can cause some really difficult to figure out bugs.

An example of a standard lookup relationship with Salesforce is the relationship between the Account and the Contact.

A couple of important things to remember about Look Up Relationships:

• By default, the lookup relationship field is not mandatory but we can potentially make it mandatory if we need to.
• When the child gets deleted the child still remains.
• If we delete a child record and pull it back out of the recycle bin the relationship isn’t restored.

We can have a maximum of 40 look ups per object.

Master-Detail Relationships

The Master-Detail relationship creates a strong coupling between two Salesforce objects which means that the child object is dependent on the parent.

The parent object really controls the behaviour of it’s children when we consider things like sharing and visibility. (Security settings for the parent apply to the child).

The Master-Detail Relationship also allows us to enforce referential integrity which means we won’t have any orphaned children. This means that if the parent object gets deleted, it’s children will also get deleted. If the child record gets deleted, there’s no change to the parent object.

The Master-Detail Relationship also allows us to create a field called the “Roll Up Summary” field on the parent object which means we can calculate values from the child records or even count the number of child records linked to the parent. (This can save us a lot of querying!)

It’s almost always in your best interests to create master detail relationships before the custom object contains data. And finally, when solution architecting a solution, it’s really important to keep in mind how many potential child records that a parent record might get.

We are only allowed two master detail relationships per object.

If you have any of these 4 requirements, then you should use the master detail relationship:

1. When the parent record is deleted all the child records attached needs to be deleted.
2. All the users who can access a specific parent record will also has access to all the related child records (parent has private OWD setting and has sharing rules on top of it)
3. wants to create rollup summary fields on parent
4. activities tagged to child records has to be shown on parent account too

If none of those conditions apply you probably want a Look Up relationship.

Hierarchical Relationship

This is a special relationship that can only exist on the user. It’s really useful to do things like store each user’s direct manager. I haven’t really used it much.

Self Relationship

A self relationship is simply an object that can create a relationship with it’s own kind. This means we can relate an object with itself by a look-up.

For example, an Account object could have a field called Parent Account which allows it to point to another account and have a self-relationship.

External Look Up

When Salesforce launched Salesforce Connect it become possible to connect an external object to another external object using the external relationship field.

It works the same as the standard look-up relationships.

Junction Objects

A junction object is used to create many to many relationships between two objects. A many to many relationship occurs when multiple records are associated with multiple records in another table.

For example, a common many to many relationship could be between Products.