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

Junction Object Explained – Works Every Time

Ever tried to explain a junction object to business users prior to implementing?

Struggle to find the right example because they can poke holes in any real business example?

Ever feel like you might as well be explaining nuclear physics to a wombat?

I want to propose one that has yet to fail me

Ever flown in a plane before?


Notice how planes carry people?

Every time you’ve flown on a plane you’ve been a junction object record.  Think about it, you have Planes and you have People.  Those two get joined together each time a person flies on a plane through a junction object known as Passenger

You can stop reading now and just use that moving forward, I promise it will work, but I’ll also keep going and point out a few useful things you can use when applying it to an actual business scenario.

I often find that removing the real world business scenario can work wonders for explaining something like this because you are able to get people to step back and think about something totally different.  Hopefully you get everyone to step back, both those encouraging change and the naysayers, and bring them back to a place where they can get a common understanding.

Relationships in Salesforce

I did touch on this in a previous post so I won’t spend very much time rehashing it here.  What I will say is that:

  • You should read the previous post
  • Lookup and Master-Detail have more differences than you may think (read the post), and that decision needs to be taken seriously
  • Junction objects are great once you get the hang of them
    • They are the notion of a many-to-many relationship
    • Standard ones already exist in Salesforce (Opportunity Product, Campaign Member, etc)

How to tell if it should be a junction object:

Can a record from Object A be related to more than one record from Object B?

Can a record from Object B be related to more than one record from Object A?


In reality this is flights, but calling it planes to business users will just be easier.  Think of a flight and you will some of the following information (fields) for any particular flight record

  • The type of plane
  • Flight Number
  • Number of Seats
  • Departure Date/Time
  • Departing City
  • Arriving City


People are just Contacts in Salesforce.  They have people attributes (ie not dog attributes).  I should not have to explain what people are so I won’t


These are the unifying element that pay for the plane, and let people go places.  They have characteristics that have nothing to do with the Plane or the Person directly, but are attributes because the person is on a plane

  • Name – This is the name from the People(Contact) record
  • Number – Let’s be realistic, passengers are just numbers to airlines anyway.  With junction objects it’s often best to use an Auto-Number field for the name because
    1. People may find naming junction records annoying
    2. It may not make sense to name junction records
  • Seat Number (Text)
  • 1st Choice or Economy (Picklist)
  • Special Meal Request (Text)
  • That loser with the carry-on that is way to big for the plane (Checkbox to be populated on check-in)


By having passengers you can also start using Rollup Summary fields to track your passengers on a plane.  For example, I created a Seat Choice picklist on passengers that is 1st Class vs Economy.

I can then do filtered Roll-ups to track how many seats have been taken.  Something like this:


So my metrics would include:

  • 1st Class Passengers (Roll-Up COUNT that has been filtered)
  • Economy Passengers (Roll-Up COUNT that has been filtered)
  • Total Passengers (Formula SUM of two above Roll-Ups)

Validation Rules

Those Roll-Up Metrics also allow me to create two validation rules that are kind of important

First Class is Full

X1st_Class_Passengers__c > X1st_Class_Seats__c

Just saying that you cannot have more First Class Passengers than there are First Class Seats

Plane is Full

Total_Passengers__c > Total_Seats__c

Just saying that you cannot have more passengers than seats.  We’ll skip overbooking for now

What happened to Economy is Full?

This one would vary but having Economy be full without First Class being full may not make sense depending on how close you are to departure.  You may want to sell an extra economy fare and then just bump someone up to first class.  You would not want to sell an extra first class fare and then bump one of them down to coach.  So instead all you really need to validate is 1st Class and Total Passengers

Putting It All Together

Your basic list of flights might look like this:

All Flights


Your people look like a list of people


When you add a Passenger record you are essentially linking up a Plane with a Contact

Passenger Record

And when you are done your Flight record would have all passengers as a related list, and the Roll-ups would be calculating as you go along.  The validation rule would kick in saying that the plane is full.



So there you have it.  I have used this with so many people now that I’ve lost count.  People ask what a junction object is or show any kind of reservations whatsoever and I just say

A junction object is like passengers on a plane

You have planes and you have people.

A passenger is a particular person on a particular plane.

They are the item that links two objects together

Hopefully that helps somebody.  Everyone I’ve used it on starts nodding their head pretty quickly and then we can get back to actually solutioning business problems.

Share Button


  1. How does one enforce uniqueness of passengers? E.g. i don’t want the same passenger twice on my plane because that’s not totally possible?

  2. This is great. Thanks, Geoff.

Leave a Reply

Your email address will not be published.


five + seventeen =

© 2018 ExploitedDevOrgs

Theme by Anders NorenUp ↑