How Salesforce Uses Junction Objects to Enrich Reporting

Did you know the Admin Relations team uses Salesforce to manage our content publication process? We publish many different kinds of content including blogs, videos, marketing campaigns, YouTube Live episodes, Twitter Spaces, and the occasional trail. We also publish on a lot of different topics like Tableau, Sales Cloud, essential habits for Salesforce Admins, Release Readiness, Slack tips, and interviews with product managers, just to name a few!

If something may be interesting to an admin like you, we want to make sure we create content to support it. And our list of topics expands with every release, acquisition, and admin area of interest. That’s a lot of content across a lot of channels and a whole host of topics!

It’s also really important for our team to regularly review and analyze the content we publish. Reporting on our content gives us a clear picture of where we have good coverage and where we may need to create some new or similar content in a new channel.

We manage this process inside our very own Admin Relations Salesforce instance.

Junction objects for the win

First, a disclaimer: Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations.

Now, let’s discuss what a junction object is. According to Salesforce Help & Training:

“A junction object is a custom object with two master-detail relationships. Using a custom junction object, you can model a many-to-many relationship between two objects.”

Our team created a custom Topic object that relates to our custom Content object. And in between them, we created a custom junction object called Content Topic. Now, a single Topic record can be related to multiple Content records, and a Content record can be related to multiple Topic records. This is what it looks like in one of my favorite—and most underutilized—Salesforce tools, Schema Builder:

Yeah, but why not a picklist?

Great question! And there’s a pretty simple answer. For this use case, picklists become a bottleneck. Remember, our list of topics is constantly growing and our team follows configuration best practices. It would take a lot of time for our SysAdmin to add new topics to a picklist, test, and deploy the changes.

What’s the benefit?

Creating and configuring a junction object is low effort and doesn’t take much time. When it’s all said and done, users (like me) can create new topic records as they need them. We can even do it right from the Content record page. Goodbye, bottleneck!

This also shows us our related topics at a glance whenever we view a content record.

Lastly, and perhaps more importantly, it gives us a powerful way to report. We can review our content by topic or vice versa, which is very useful. And we do this in our content dashboard for the year.

Cool, right? Now go get started!

If you’ve never tried using a junction object for reporting, now’s the time! The applications are endless. In fact, if you’re looking for a practical use case, why not try the example from this Help article? Create a custom Bug object and a custom Bug Case junction object. The end result is that your users can submit a case if they have a Salesforce issue, and you can relate many cases to a single bug or many bugs to a single case.

Resources

• Trailhead Project: Build a Data Model for a Recruiting App
• Trailhead Module: Data Modeling
• Salesforce Help: Create a Custom Report Type