In this episode of ShellBlack Whiteboard we finish up our series on custom objects with a "many-to-many" data relationship. Shell walks us through an example of registering for Dreamforce to illustration how a custom object with two lookup relationships becomes a "join" object in the database.
View this video on YouTube: http://youtu.be/PArdXLnSJv0
Part 1 on Custom Objects: Introduction to Custom Objects
Part 2 on Custom Objects: "Master-Detail" Data Relationship
Transcript of video:
Hello everyone. Welcome to another edition of ShellBlack Whiteboard, where we help you get the most out of the Salesforce platform. I’m your host, Shell Black, president and founder of ShellBlack.com and Salesforce MVP.
We’re going to continue our conversation around custom objects. I wanted to give you the example of what a "many to many" relationship looks like in Salesforce. To do that, I’m going to use an example of registering for a Dreamforce session.
Let me explain a little bit of this football play here on the whiteboard. I have two custom objects. The first custom object is a Dreamforce session. I’ve got session one, session two, session three. I have a second custom object that’s a registration custom object. It has two lookup relationships. One lookup custom field goes to the Dreamforce session. The other lookup goes to a standard object, the contact record. Because I have two lookup relationships, I can relate multiple sessions to multiple contacts, or many contacts to many sessions, in various combinations. Those combinations is that "many to many" relationship that I want to illustrate here.
Let me just walk through this with you real quick. Contact number one was really excited about Dreamforce and registered for all three Dreamforce sessions. So, it is registration record number one, session one, registration record number two, session two, registration number three, session three. He’s registered for Dreamforce. Contact number two is only going to register for the first session. So, registration record number four for session one. Contact number three signs up for two sessions, registration record number five to session one, registration number six to session three. Contact number four signs up for two Dreamforce sessions, session one – so all of our Contacts register for session one – and Contact number four registers for session three.
How does this "many to many" relationship look on our records? If I took Dreamforce session number one… This is supposed to represent the session, and it could be the date and time, a field for location, a field for speaker, a field for topic, whatever it might be, below that. Because of this registration relationship, I will see all the Contacts – Contact one, two, three, four – and their registration. This is registration record number one, registration record number four, number five, and number seven. On this Dreamforce session and related list, because I have this lookup relationship, I can see all the related contacts in that many to many relationship.
If I flip to this side of the board, let’s kind of look at the converse or the reverse relationship in this "many to many" relationship. If I’m looking at Contact record number one, we’re going to see that he registered for all Dreamforce sessions – session one, session two, session three, – through that join table, which is our registration, registration record number one, registration record number two, registration record number three. This registration custom object is our join between these two different tables, the Dreamforce session table and our Contact table through these two lookup relationships in our many to many relationship.
That’s it. That wraps up our discussion on custom objects and standard objects in a "many to many" relationship. I hope you enjoyed that.
If you have any feedback on how we’re doing, we’d love to hear it. You can reach out to us a couple of different ways. I’m available on Twitter @Shell_Black. You can always email me at firstname.lastname@example.org. Thanks so much for tuning in, and we hope you watch the future episode.