Relationships
Relationships refer to the various ways in Salesforce in which records can be related to each other. Ranging from Lookups to Hierarchal relationships, Salesforce is very flexible in it’s architecture possibilities.
Components of Relationships
Lookups
Lookups exist in two core types, a “Standard” lookup field, which at it’s core does not require a value to be populated, and can be associated to any other object. As well as a “Master Detail relationship”, which drives a requirement that anywhere a master detail lookup exists, it be populated, as it defines the record can not exist without the “parent”.
Lookup Filters
Salesforce allows you to define optional and/or required filters when creating lookup fields. This can help pre-filter results when trying to find records.
Roll-up Summaries
Roll-up summary fields, although separate field types, are a result of a master-detail relationship being present, which gives the user the ability to “roll-up” values from children records to the parent.
How to build Relationships in Salesforce
At it’s core a relationship is the joining of two (or more) records in Salesforce, defining some level of relationship. Most commonly you think of “Parent to Child”, “One to Many” or “Many to Many”. Each of these terms alludes to a desired end result in the function of the Data architecture you are defining. A parent-child relationship can help build a “hierarchal” structure, think of the OOTB Account Hierarchy as an example.
One to Many and Many to One are inverse perceptions of a similar relationship, for example, a Contact and an Account being related. From the contact level, you can associate one contact to directly to one Account. That account however, can be related to many other contact records.
Many to Many uses junction objects to expand on this relationship, OOTB an example would be the Account Contact Relationship, which allows you to utilize a junction object and expand upon a contacts primary Account relationship, linking it to other Accounts with various roles.
As briefly touched on above there are two types of lookups, a traditional one and a Master Detail. From an Account perspective, you could add a lookup to a custom object you created, and choose whether or not to populate that lookup, making it not master detail.
Contacts however, can’t be present without an Account, making that lookup a Master Detail. Master Detail lookups allow you to create rollup summaries that will give you added features at the parent record level. If you were tracking at a contact level, the amount of cases the contact was linked to, you could take that number and roll it up to the parent account, giving insight into how many cases you have for the entirety of your Account. You can filter those rollups to only show things like Open Cases or Closed Cases, or the most recent case even.
Junction Objects create the ability to relate two indirectly related records to each other as needed. You can use traditional lookups or master detail, depending on how you want that object to function. This was touched upon earlier in how Account Contact Relationships function, but we can add a different example to provide more clarity.
Say you had Training Sessions as an object in your org. You wanted to track what learnings you were given, when they happen and who attended. The training Session would be the Junction Object, with lookups to the Learning Content, Contact, and a Training date. This would allow you to then utilize master detail relationships and create roll up summaries or simplified reporting means.
Who is Impacted?
Admins
Admins are responsible for their data architecture design and should carefully consider what lookups they utilize and how they implement features like filters and master detail relationships.
End Users
End Users will see gained efficiencies from a refined architecture structure that allows them to more easily track and report on related records.