In this episode of ShellBlack Whiteboard we dive further into custom objects, and more specifically, custom objects in a “master-detail” data relationships. Shell walks us through an example of a master-detail relationship using an Expense Report. Because of this data relationship, records can be tabulated using Roll-up Summary fields. This can be very helpful in many situations for System Admins. Then he gets into a section called “Things to Know.” When we have a master-detail relationship what happens when you delete a record? What kind of object can be the master? How is security determined? What is the impact to Record Ownership? Can you re-parent child records?

View this video on YouTube: http://youtu.be/yaW5g6HsZDM

Part 1 on Custom Objects: Introduction to Custom Objects

Part 3 on Custom Objects: “Many to Many” Data Relationship

Transcript of video:

Hello, everyone. Welcome to another edition of ShellBlack Whiteboard, where we help you to get the most out of the Salesforce platform. I’m Shell Black, President and founder of ShellBlack.com and Salesforce MVP. And we will continue our conversation around Custom Objects and we’re going to talk about Custom Objects Set in a “master-detail” Relationship.

So let’s take a look. So to set the stage, I’ve got two custom objects. I’ve got one custom object called an “Expense Report.” So it’s going to have fields like, who submitted the expense report, where do you travel to, the date of travel, purpose of the trip, and so on. And then I’m going to have another custom object for my “Expense Report Entries.”

Example Fields on Expense Report Custom Object:

Example Fields on Expense Entry Custom Object:

So these are going to be my receipts from the trip. So my airfare receipt, my rental car receipt, my meals and so on. What’s unique in how I’m going to tie these two custom objects together is I’m going to put them in a “master-detail” relationship because I want to roll-up my totals of all my receipts up to the parent in these roll-up summary fields.

So let’s talk about how we do that. So if you’re creating a new field on a custom object, you can do a lookup relationship or you can do a master-detail relationship. A master-detail relationship is a little unique and to me when I’m deciding on which one to use, the big criteria is do I want to roll up anything to the parent in this child-parent relationship? If so, I’m probably going to want a master-detail relationship. There’s some other things you need to know. I’ll talk about that in a second.

So on my expense entry custom object I’ve a picklist called, “Category,” which is allowing me to segment my entries into airfare, rental car, hotels, meals, etc. Once I have this master-detail relationship established, I now have a new field type called, a “Roll-up Summary Field.” So what I’m going to do is put fields to summarize my airfare, meals, etc., using roll-up summary fields and tabulate information from my child records.

When I create a roll-up summary field, I had a couple of options that I could pick up from. There’s a count, so it’s just counting a number of records in the child relationships. So in this case I have five, so if I did that type of roll-up summary on my parent, it will count five. Or you can use, a sum, and the sum is what I’m using in this example for summarizing the amount of each receipt of my expense report up to the parent. You can also have a minimum and maximum. So I’ve got a blue asterisk here just to let you know what you can summarize. You can summarize a number, a currency, which is the example I’m using here or a percent. Minimum and maximum has a couple of more options. A number, a currency field, a percent or date or a date/time. So let’s say that I want to know the last entry, the maximum date I could do that or if I wanted to get the maximum amount, maybe I want the most expensive entry, I can use a maximum summary field.

So when I’m adding these summary fields to my expense report objects I have filters available. So just like you’re creating in a view, you can pick a field on the child object. I want to pick the category picklist and I’m going to write a filter, says, “Category equals airfare.” And that’s going to be the filter I’m going to use on this roll-up summary field. So I’m only summarizing fields that make that specific criteria. So I’m not summarizing all, I’m only summarizing where the category equals airfare.

So you’ll notice on this one: meals at $35 is actually calculating and summarize these two entries. So I would’ve created a filter that says, “Summarize your summary calculation where the category equals meal,” and then summarize that amount. So that’s why that’s $35. Super, super helpful when you want to roll up that information to a parent without using a trigger, schedule job or code.

So a couple of things because a roll-up summary is really a formula that’s calculating when you’re in an edit mode on the parent, those skills are not going to be available and then you have a limit of 10 summary fields on that object. I have an asterisk here on that limit because you can open a case with SalesForce and have that bumped, I believe, to 20.

All right. Let’s get to this side of the board and call out a couple of things to know. So we’re setting security on an object that’s in a master-detail relationship, you set the security at the parent. So let’s take our expense report custom object. If I have the expense report parent in private, that puts all the associated child records in private as well. So if I can’t see the expense report, I won’t be able to see the expense report entries. You set the OWD — organizational-wide default default — at the parent and that cascades to the child.

SalesForce does recommend and that you only have 10,000 or less child objects in a master-detail relationship, I assume that’s for performance and calculations. If you delete a child record, the master record still stays. So if I delete an expense report entry, I’m not going to delete the parent for the expense report.

However, if you do the reverse and you delete the parent, the expense report for the Chicago trip, all the child records, all the expense report entries will be deleted. You can always undeleted it via the recycle bin and all that will come back to life in a relationship again, but just realize if you delete the parent, you’re going to delete the child records as well.

When you create your master-detail relationship, there’s a checkbox — on when you’re creating that master-detail lookup relationship — to ‘allow re-parenting.’ If ‘allow re-parenting’ is checked, I can move in my example an expense report entry to another expense report. So let’s say I have two expense reports, I have the Dallas trip and the Chicago trip. If that checkbox is checked, I’ll be able to take that entry for, say, airfare, and moved it from Dallas and put it up against the Chicago trip. If that’s not checked, when you set up that relationship, I would have to delete the airfare for Dallas, and create a new record for Chicago.

So let’s talk about what could be on the master side of the master-detail relationship. A master can be a standard object or a custom object. You can also have on an object with up to two master-detail relationships. So a child object can actually have two parents in a master-detail relationship. Record ownership is determined at the parent level, at the master level. So if we think about our expense report that we’re just talking about, you’ll see a record owner field at the expense report level, but you’re not going to see a record owner field at the entry object level.

Salesforce assumes that in that type of master-detail relationship, we really just have ownership at one level. All right. So there’s kind of a gotcha here because I just told you earlier that you can have up to two master-detail relationships on an object. So what happens on record ownership and who’s the record owner when you have two parents? So the first object that you throw in a master-detail relationship become the “primary.” So when you do things like workflow and you have a workflow rule that is assigning a task to the record owner, that workflow rule is going to work for the first object you threw in that master-detail relationship or the “primary” object. And that’s the record owner that’s going to get the task. Kind of an obscure use case, but that’s a gotcha that will get you now and then.

All right. That wraps up our episode on “Custom Objects in A Master-detail Relationship.” I hope you would like that one. If you have any feedback on how we’re doing, you can hit me on a couple of different ways. I’m out on Twitter @Shell_Black or you can email me at whiteboard@shellblack.com. Thanks so much for tuning in and I hope you’ll watch a future episode.