Saving $$ with Salesforce
Relationships can, “Save. You. Money!”
Some peeps believe that we’re all related. I guess if you go all the way back to “Lucy,” then yeah, maybe we are?
I’m not here to debate evolution or not. I’m talking about Salesforce objects and how Objects can be related. And more specifically, I’m going to show you how objects behave with each other when they are related. Creating relationships between objects are like friendships — they’re your chosen family and you “share” information with each other. Anyway, in planning your data model aka family tree, consider the object hierarchy.
So, what’s an Object? It can either be Standard or Custom. “Standard Objects are objects that are included in Salesforce.” Are you laughing because that wasn’t much of a definition? I literally took this verbatim from a Trailhead — and it made me laugh!
All jokes aside, objects are database tables that allow you to store specific data within your Salesforce org. On each object, you’ll have fields where you can store data. Standard objects are tables that are out of the box within Salesforce: Accounts, Contacts, Leads, Opportunities, Case, etc. Accounts and Contacts are like the Mama and Papa of standard objects because you shouldn’t have a record without a related Account and Contact. And Custom objects are tables that you create to store data that is specific to your business model.
In The Giving Tree Foundation project that Abby and I created for Talent Stacker, we created a Donation Management app. The client asked us to customize the labels of some standard objects, but if you stay very still, you may be able to spot the standard one’s below. Potential Donors = Leads, Donors = Contacts, and Donations = Opportunities. The Custom objects that we created to fit the clients needs are: Event Roles and Other Roles.
One of the requirements was to create a field called Event Role to capture whether a donor could be an Honoree, Host, Speaker, Vendor or Volunteer. A donor could have more than one event role so they asked if the field could be set up as a multi-select picklist. And each role is listed as a value on the picklist.
Another requirement was to create a field called Other Role to capture whether a donor could be a Celebrity, Consultant, Employee, Intern, Partner, Potential Partner, Storyteller, or VIP. Again, a donor could have more than one other role so they asked if the field could be set up as a multi-select picklist. And each role is listed as a value on the picklist.
This is where experience with data modeling helps. Inherently, we knew that fields that have Multi Select Picklist data types are not reportable and they’re massive in size so they can be unattractive on the page layout. We suggested making the Event Role and Other Role fields into Custom objects instead. By making them custom objects, the client can easily see all Roles directly on the Donor’s record and they can run reports!
First, we created the 2 custom objects from the Setup/Object Manager:
But these new custom objects are independent of all other objects right now, orphans — no relatives. So we created a “Contact Name” custom field on each custom object with a lookup relationship to link (creating the relationship) the standard Donor object to each of the custom Role objects. And now you can have a One to Many relationship between Contact and each custom object: one Donor to many Event Role or one Donor to many Other Role. How did we know to create the field with a Lookup data type vs Master-Detail relationship? If the field does not need a rollup summary, then make it a lookup relationship data type.
When creating the custom “Contact Name” lookup relationship field on the Event Role or Other Role object, we define that it’s related to the Contact object; making the Event Role object the “child” object in the relationship. And because we created this custom field thru the child’s object manager, it inherently makes the Contact object the parent within the relationship.
Lookup fields exist on the child object because the child needs to look “up” to the parent to get the data. Get it? “Look-UP” to get the data! You can’t create a lookup relationship data type field on the Parent object when the data is on the Child because the Parent has to look “down” to the Child to get the data. To update fields on the Parent object with data found on the Child object, you can create a flow, but that’s for another post.
Once the relationship between the objects is established through the lookup field, the Child object can be selected to display on the Related List of the Parent object. By simply relating the parent Contact object to the child objects: Event Role / Other Role, the child objects become available as a Related object to be displayed on the parent object. Let me show you — here’s Cookie’s donor (aka contact) record. We added a Related List Quick Links section on the Donor lightning record page to display the related objects. See, Event Roles and Other Roles appear in the section with “(0)” is to the right of the name. That means no record for the Role has been created yet.
If you hover your cursor above any of the objects in this section, a pop up box will appear with a “New” button at the top right corner. Click on the New button to create an Event Role for Cookie. From the down arrow in the Event Role field, you can select from Honoree, Host, Speaker, Vendor or Volunteer.
Once you click on Save, an Event Role record will be created and you can create more records by clicking on the New button and repeating the process. More than one Event Role record can be created for Cookie so this functionality meets the client’s requirement of capturing multiple Event Roles per Donor — in this example, we created 3 Event Role records. Now when you hover your curser over Event Roles in the Related List Quick Links section, you see 3 Event Role records. Cookie is willing to be an Honoree, Volunteer or a Speaker.
The same process to create Other Roles can be applied. From the drop down arrow in the Other Role field, you can select from Celebrity, Consultant, Employee, Intern, Partner, Potential Partner, Storyteller, or VIP.
When you’re done creating records for all the Other Roles that apply, you can see the complete list when you hover over Other Roles. For this Cookie example, we created 2 Other Role records. Cookie is a Celebrity and a Potential Partner.
And the # of records will update in the Related List Quick Links section for Event Roles (3) and Other Roles (2) based on the # of Event or Other role record you created.
Recommending the use of custom objects instead of using a multi-select picklist field makes the Donor page layout less cluttered, yet the information is still visible on the donor page and it’s now reportable!
When it’s time to plan an event, the Events Manager may want a list of Donors that are willing to participate. So we created reports off of the Event and Other Roles object to list the donors that are willing to participate / grouped by the Role. And we even included the Donor’s contact info on the report so the Event Manager didn’t have to look that information up.
Leveraging object relationships to present organized information allows Users to be more productive because they can find information faster. And when a User can glance instead of click to get that information, that saves time and money! And saving money is definitely in your client’s DNA…
In case you’re curious, here’s the heroic story of Mattress Mack!
Mahalo,
Lizette
