Q: What’s a junction object? What problem does it solve?
In a previous post, we talked about the different types of object relationships.
One type we didn’t mention was the many-to-many relationship. I will spare you some weird diagram, they all look like various types of spiders and give me goosebumps. Rather, I’ll give you a real-world example.
On Saturdays I play soccer with my friends. We rent a field at a park, we all chip in a couple dollars, and we have about an hour. That hour usually follows the same template: we put on our shoes, we stretch, we chat, and then eventually we get around to setting up our teams so we can finally fulfill the purpose of our gathering: to run around and scream at each other in disappointment as we sweat out our hangovers and worries.
So I’m a member of this group which plays soccer. In this way, we’re related, just as objects are related and data can be modeled in Salesforce. Our objects here are:
- Soccer Game (“Saturday”)
- Soccer Player (“Luc”)
Each soccer game will have multiple players (playing alone isn’t much fun), so what we’ve modeled is a one-to-many relationship. One game, many players. This is a pretty standard relationship that we model all over the business world. Accounts and contacts, customers and orders, managers and employees, etc.
I have another group of friends who likes to play more sporadically, usually on Thursdays. Occasionally I join them, and in that sense I actually belong to more than one game. In joining more than one game, I’ve morphed our data model from one-to-many into many-to-many.
You see, if I’m related to two different games, and each of those games is also related to multiple players, we encounter a puzzle that we can’t solve without introducing another piece. So, how can I belong to two games at a time? Enter the humble but powerful junction object.
- Soccer Game (“Saturday,” “Thursday”)
- Soccer Player (“Luc”)
- Participant (“Luc on Saturday,” “Luc on Thursday”)
Participant is our junction object. It serves to connect me, the soccer player, to two games at once, one on Thursday and one on Saturday. In the business world, we have lots of examples of this as well. Jobs, applicants, and job applications are a classic one. Students, classes, and enrollments are another. In these cases, a job application serves to join an applicant with one or more jobs, and an enrollment joins a student with one or more classes.
To bring this full-circle, let’s name a few junction objects that come out of the box in Salesforce: opportunity products unsurprisingly join opportunities with products, and pricebook entries join products with pricebooks.
Remember I’m talking about games, not teams, since my friends and I are adamantly disorganized and we just make our teams on the fly. In the world of professional sports, this looks a little bit different.
It goes without saying that I’m not a professional soccer player. I mean, very, very far from it. However, If I were Lionel Messi, and I signed a contract with a professional club, it would undoubtedly bar me from joining any other teams. So, the model will always remain one-to-many: one team, many players and not one player, many teams.
So I guess the silver lining here is that my dire lack of skills actually gives me more options. Hooray!