6

Why can't we create a master-detail relationship in which the User or Lead objects are the master, any particular reason?

7

Well as John Gaughan says, the basic reason is "because Salesforce says so" or perhaps I would phrase as "it's a platform limitation."

Architecturally, it is because there are limitations in the Salesforce platform due to a Salesforce architecture characteristic that could be phrased as "all objects are equal, but some are more equal than others."

Some of these are justifiable from a software design perspective: User in particular could be argued needs to not be just a basic first-class object, since it governs security, licensing, and has special needs (like usernames being globally unique). That doesn't (IMO) justify not being able to have M-D relationships at this point, or why the page layouts of User don't have the flexibility of other objects, but that's what we've got.

Others are because the objects are very old and were hard-coded to behave in certain ways way back in the day and Salesforce hasn't gone back and updated these to the "new world". In this camp, you'll find things like Lead, Campaign, CampaignMember, Attachment, Activity, PriceBook, Product2, [Object]History, Queue, etc. You'll also find weird fields like Opportunity.StageName, Opportunity.CloseDate, CampaignMember.Status, the Integer field type, and the awesome-yet-still-unavailable-to-custom-object polymorphic lookup fields like WhoId and WhatId.

Others are reverse limitations where Salesforce has the privilege of granting "their" objects behaviors that are not extended to the general platform, presumably because it always costs way more to "platformize" the feature. Chatter is a good example, as are platform-level features like portals & communities, groups & profiles, queues, etc.

15 years on, it's pretty easy to look back in hindsight and from the perspective of language/platform development say things like "why is not an SObject simply always an SObject?" or "why is the Salesforce Limits Quick Reference Guide 38 pages long?"

If you were developing a Salesforce-like platform based on what we know Salesforce is today, many of these decisions would probably not have been made. But Salesforce morphed from a fairly straightforward SaaS customer database system into the massive platform it is today over many years, and along the way, many compromises, cost-benefit tradeoffs, customer demands, and difficult/questionable design decisions were in the mix. And many times that results in a platform that isn't as elegant as it could be or has limitations that we (as developers) find frustrating. I'd recommend changing your line of questioning from "why can't I do (X technical thing)" to "how can I solve (X business problem)?" because despite some of the frustrating technical limitations, you can accomplish almost anything on the platform.

TL;DR: because that's the way it is :)

  • 3
    That is what I was getting at in my comment, I was just giving the very simple explanation. Between the evolution of the platform and subtle technical reasons for certain objects behaving uniquely, it probably makes sense. But the details are a matter of speculation and a healthy dose of common sense, unless someone who sat in those first design meetings decides to provide an answer. But you are absolutely correct that "how" questions are better than "why" questions: "why" tends to be purely academic, while "how" provides real-world solutions. – user6861 Mar 4 '14 at 14:32
1

This is by design and is documented.

"You can define master-detail relationships between custom objects or between a custom object and a standard object. However, the standard object cannot be on the detail side of a relationship with a custom object. In addition, you cannot create a master-detail relationship in which the User or Lead objects are the master."

http://www.salesforce.com/us/developer/docs/api/Content/relationships_among_objects.htm

  • I don't see any "why" in your answer. – Keith C Mar 3 '14 at 9:46
  • MnZ didn't ask why SFDC decided to not have md for User and Lead. But he did ask why we can have this relationship. The answer is because it is stated in doc. – Andrii Muzychuk Mar 3 '14 at 10:08
  • @Chiz Mnz already knows the master-detail relationship can't be created; all the documentation does is confirm that. The question was "why" and "any particular reason". – Keith C Mar 3 '14 at 11:14
  • 1
    I think a more accurate way to answer this is "because Salesforce says so." Technically accurate yet adds nothing to the conversation -- but unless a Salesforce employee with knowledge of this design decision chimes in, it is also likely to be the best answer we can come up with. – user6861 Mar 3 '14 at 15:41
  • 1
    I used to work for Salesforce support and this question came up in cases every once in a while, but there was nothing documented that was at available to support. I remember someone saying that in the case of leads is because it gets converted and that would prevent that relation. I don't think I have an explanation for Users but it doesn't sound illogical to me given the nature of that table. – PepeFloyd Mar 3 '14 at 20:32
1

Probably I can think off the reason to be Lead Conversion. While Lead gets converted to Account, Contact and Opportunity the parent record is not visible and there wont be any reference to the Lead record. Hence I believe Salesforce doesn't allow Master Detail relationship on lead.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.