Who’s Your Daddy?

February 27, 2013 Appirio

by Andres Gluecksmann (@aglue)

Since the Spring ‘10 release, Salesforce opened up the possibility of creating a child record that has two masters (Master-Detail relationship type). With two masters, interesting requirements can be met with simple manipulation of the force.com data model. With two masters however, a variety of interesting questions arise.

What happens if…

  • Security wise, a user has access to only one of the two masters? Do they get access to the child record or do they need access to both parents?
  • A report or list view is run based on “My {Child Record}” filters – knowing that ownership of a child record is adopted from the Parent – what if two different users own each of the Parents? What data returns if any?
  • If I want to create a Workflow Rule on Child and assign a Task to the Parent record owner, which of the two Parent records can I assign the Task to? Both? Either? Neither?

Not long ago I spent a couple hours deep diving on all these questions because, I just had to know “Who’s my daddy?”

What I found out…

  • When two Master relationships are established to one Child, salesforce in fact designates one of them as the “Prime” Master.
  • A user must have at least read access to BOTH Parent records in order to access a Child.
  • Child Workflow rule actions for Task creation offer the assignment of the task to Prime Master record owner only. Not both Parents (this one made me sad).
  • List view and report filters based on Child records like “My {Child Record}”, returns records where the user owns the Prime Master record only.

Ok, so how can I tell which is Prime?…

The order in which you create the Master-Detail relationships is key. The first Master-Detail you establish is marked Prime.To confirm which is Prime, simply check out the order in which the objects appear at Setup>Create>Objects, the first object in the list is Prime.

Dad is prime!

Ok, so now you tell me. I need to switch the Prime! Can I?

Yes! You can and operation “switcharoo” is pretty straight forward:
In the case above I need Mom to be prime.

  1. Go to the Dad relationship field (on Child object) and change the field type to “Lookup”.
  2. Immediately change the Dad field type back to “Master-Detail”.
  3. Mom is now Prime!
 Mom is prime, go Mom!

Caution: If you conduct operation “switcheroo” in an environment where new records are being created (via users most likely), you may find yourself stuck with child records that now need to be either deleted or linked to a Parent before you can switch the Lookup back to Master Detail. Basically, any errant child records created in the moments between the “switcheroo” can cause you trouble since the Lookup relationship is momentarily not required.

Existing child records should be safe since their relationship to the Parent will be preserved even during operation “switcheroo”. I did this operation 5 times in a sandbox with millions of records, it went smoothly.

P.S. – Be aware that as of this blog post, a “Known Issue” exists for “Activity with {Child}” type standard reports where the child has two masters. Hopefully this issue will be addressed soon, but as it stands now these type of activity reports are not available (you get an “Obsolete report” error when trying to create). Custom Report Types are a close workaround for this need but aren’t quite the same since you lose the “My Activity, My Team’s Activities” type report pre-filters.

Previous Article
Deliver Value with Unit Testing in the Cloud
Deliver Value with Unit Testing in the Cloud

By Geoff Escandon (@gjescandon) Unit Testing is an evergreen subject. On the Force.com platform, 75% of you...

Next Article
Tutorial: Creating an AngularJS app with node.js and Heroku Part II
Tutorial: Creating an AngularJS app with node.js and Heroku Part II

by Bryan Leboff So now that we have our environment set up from Part I of this tutorial, it’s time to start...