Changing the way Salesforce Admins and Developers think about client solutions.

Explaining Salesforce Relationships – in normal terms


This doesn’t have much to do with a dev org, but does have everything to do with understanding the platform enough to be able to explain to someone in real terms what the different relationship types are, and what the impacts are of each choice.

There are two main relationship types in Salesforce:

Master Detail: Closely links objects together such that the master record controls certain behaviors of the detail and subdetail record. For example, you can define a two-object master-detail relationship, such as Account—Expense Report, that extends the relationship to subdetail records, such as Account—Expense Report—Expense Line Item. You can then perform operations across the master—detail—sub-detail relationship.

Lookup: Links two objects together. Lookup relationships are similar to master-detail relationships, except they do not support sharing or roll-up summary fields

There are also three types of relationships:

One to One: You would create a lookup or master detail, but enforce a unique constraint with a validation rule, or say that the count of child objects cannot be greater than 1.

One to Many: Can be a lookup or a master-detail relationship.  Out of the box both are one to many.  You always create these on the Many side, to lookup to the One.

Many to Many: This is a junction object.  You basically create two master-detail relationships, one to each master object and this child object sits in the middle.

Make perfect sense?  Good, I won’t keep going then…..

So how do you explain this to someone who doesn’t understand technology speak?  You break it down into something they do understand.  I had to do this today with someone and I started talking about the parent child relationship, and the issues with a many-to-many relationship when it all just kind of came together.

I usually start by explaining that in a master-detail, the detail records are much more closely tied to the parent.  It may not even make sense to have a different parent record listed, they are that closely linked.  In a lookup relationship the child doesn’t really care who the parent is, they can move at any time.


So what does this have to do with a family in silhouette and why is it there?

You mean besides the pretty sunset?  It’s because I think that this explains things pretty well

Let’s pretend that the parents are one record for now, which would make the kids  the child object records.  They inherit just about everything from their parents, and they would not easily be “re-parented” to another set of parents.  They are directly tied to the parent record.  If you were reporting on families, you would also probably report from the parents down – keep this in mind for later.

Now look at the bike and stroller.  Do they really care what parent record they belong to?  Not really.  Right now the kid has a small bike and the baby has a stroller.  What about in 3 years?  The kid will have a new bike, and the baby will be riding that one as a hand-me-down.  So they can be transferred much easier between parent records.  Also, if you were reporting on something like this, you would typically report on the bike or stroller itself, and maybe who currently has it, but the person currently riding it wouldn’t be the focus as much as the bike.

So what if the parents were two records?  This is where it gets tricky and you have to be very careful for reporting.  A many-to-many relationship is a disaster for reporting.  Here are a couple reasons why:

  1. Say you wanted to report on all parents with children.  So just having these two parents in the report with two children means that in total you have 4 child records in the report.  It’s very easy to accidentally send out wrong numbers
  2. Say you need to know for the school what phone number to reach the parent at and wanted to automate that on a report of children – something like an emergency number.  The report doesn’t know which parent to go get it from, because there is more than one of them.  This is the crux of many-to-many relationships in Salesforce, it’s like having two bosses at work.

Here’s another attempt at explaining it:

Relationship Diagram

Can you tell I won the art award in Grade 8?  Because I did.

Me reporting on my underlings?  No problem, just roll them right up under me and I’ll take credit for everything.

Me reporting to my bosses?  Who am I supposed to tell what to?  If I need to tell someone else who my boss is, who do I use?  Do I have a primary boss?

My Bosses reporting to the CEO – In general, CEOs are pretty smart, and here we have two people under that person both trying to take credit for my work.  Someone is about to look very bad, and that person won’t be me.  Maybe they’ll both get fired and I’ll get that job.

Now  that we have a few examples, let’s go back to why we would you use Master-Detail vs Lookup?


  • Inherits security from the parent – parents pretty much control their children’s lives in real life, just remember that.
  • Permits Rollup values on the parent record from all children – you can safely say that the parent has two children.
  • Master is the primary object in custom reports – you are reporting on parents with children


  • Child records have their own owner and therefore security.  The kid doesn’t own the bike forever, probably because they’ll forget all about it when they get a shiny new bike
  • Does not permit rollup values – I find it annoying that they don’t, check out this solution once you are comfortable with more technical solutioning – still no code!
  • Child is the primary object in custom reports.  This would be bikes with kids for example.

The third item there often gets overlooked but is really important if you need a lot of cross-object reporting.

Make sure you always understand what they are trying to report on, and build the data model accordingly.  Too often I see a many-to-many relationship built to satisfy the 1% of items, but it basically blows up 100% of the reporting capabilities, so don’t do it.

If you have to do it, make sure you have a Primary record and identify it as such.  You may have to apply some code on top of it, but at least you’ll have a fighting chance.  Go back to my beautiful flow chart from above.  If I could identify my primary boss, everyone would be much happier and have a better idea as to where they stand.  I would also know who to go to for more money.

Share Button


  1. Your link is not working on this line: “check out this solution once you are comfortable with more technical solutioning – still no code!”

    I have been looking for rollup ability on lookup relationships for a while, and finally found Declarative Lookup Rollup Summaries. It’s been working great in my production org! Check it out.


  2. Nice article Geoff. Can you check the link above called “this solution” towards the end where you talk about roll up values on lookup fields? Didn’t work for me. Thanks!

Leave a Reply

Your email address will not be published.


eleven + twenty =

© 2018 ExploitedDevOrgs

Theme by Anders NorenUp ↑