When the Data Model Shares for You

Module 6 of 7 in the chapter Org-Wide Defaults, Ownership and the Role Hierarchy, chapter 6 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: Before you write a single sharing rule, your data model has already made sharing decisions. Which ones, and how do you choose them on purpose?

When I teach data architects about master-detail, I call it a very tight binding. You can’t have a child of a master-detail without the parent. The Owner field on the detail object goes away, and it inherits the owner of the parent. So the child loses its own ownership. There’s no share table. You can’t share the children. They inherit the sharing of their parent.

That’s a data model decision with a sharing decision inside it. In the sharing class I put it the other way round: if you see the master in a master-detail relationship, you see all the children. This module is about choosing that on purpose.

Two kinds of Controlled by Parent

You’ll see Controlled by Parent in two places, and they come from different decisions.

The account family. Contacts, orders and activities can be set to Controlled by Parent on the Sharing Settings page. Those objects defer their privileges to the parent. If the account is public, they’re public. If the account is private, they’re private. If you can see the account, you can see these children. That’s a setting you choose, object by object, and module 2 covers it.

The detail of a master-detail. Here nobody chooses it on the Sharing Settings page. It comes with the relationship. “Detail and subdetail records inherit security settings and permissions from the master record. You can’t set permissions on the detail record independently” (Object Relationships Overview (opens in a new tab), Salesforce Help, checked 2026-11-07). The person who picked Master-Detail Relationship in the field wizard made the sharing decision.

What a detail gives up

Salesforce spells it out on the same page. “The Owner field on the detail and subdetail records isn’t available and is automatically set to the owner of the master record.” And “Custom objects on the detail side of a master-detail relationship can’t have sharing rules, manual sharing, or queues, as these require the Owner field.”

Put that next to module 1. A detail has no share table of its own; the master’s share table decides. So every way of sharing that writes a row is gone for the detail. You don’t share a line item. You share the order it belongs to, and the line items come with it, all of them.

It reaches into the offices, too. On a profile or permission set, some permissions on a child turn on permissions on the parent: if the child has View All Records or Modify All Records, the parent gets View All Records; if the child has Read, the parent gets Read (same page). Give someone View All on the details, and they get View All on the masters.

Click to enlarge

There’s one choice you do get. When you create the master-detail field, you pick its Sharing Setting: Read Only or Read/Write. It “determines the sharing access that users must have to a master record to create, edit, or delete its associated detail records” (Create a Many-to-Many Object Relationship (opens in a new tab), Salesforce Help, checked 2026-11-07).

Read it as a question: to add or change a detail, must you be able to edit the master, or is reading it enough? Read/Write keeps the details as locked as the master. Read Only lets people who can only read the master add, edit and delete its details. Sometimes that’s right: anyone who can see a project may log time against it. Decide it on purpose, because it’s easy to click past.

Two masters: a junction object

A custom object with two master-detail relationships is a junction object, and it has two masters to answer to. “Sharing access to a junction object record is determined by a user’s sharing access to both associated master records and the Sharing Setting option on the relationship field.” Salesforce’s example: “if the sharing setting on both parents is Read/Write, then the user must have Read/Write access to both parents in order to have Read/Write access to the junction object” (Considerations for Object Relationships (opens in a new tab), Salesforce Help, checked 2026-11-07).

So: ownership from the primary, access from both, and the most restrictive wins. The junction’s owner comes from the primary master, the first master-detail you created (same page). But a user who can see the case and not the bug doesn’t see the link between them.

Click to enlarge

A lookup is the other choice, and for sharing it’s the opposite. Lookups are like master-detail “except they don’t support sharing or roll-up summary fields” (Object Relationships Overview). The child keeps its own owner, its own org-wide default, and every way of sharing on the map.

When I model, I decide master-detail versus lookup on the diagram, before anyone builds anything. The Data Architect course asks the lifecycle questions: can it exist alone, can it change parents, what happens when the parent is deleted. For sharing, ask three more:

Does the child need its own owner? If a person works the child, separately from whoever owns the parent, it needs a lookup.
Must some people who see the parent not see some of its children? A master-detail can’t do that with sharing. Make it a lookup. I’ve heard of teams putting a restriction rule on the details to filter some of them out. Salesforce lists custom objects as supported, but I haven’t seen it say anything about detail objects, so test it in a sandbox before you rely on it. Chapter 16 covers restriction rules.
Does everyone who sees the parent need all of its children? Then master-detail fits. You get one place to share, and fewer share rows to calculate.

One warning about the lookup’s own delete option. On a custom object, a lookup can be set to delete the child when the parent is deleted. Salesforce warns that this “can result in a cascade-delete. A cascade-delete bypasses security and sharing settings, which means users can delete records when the target lookup record is deleted even if they don’t have access to the records” (Considerations for Object Relationships). It’s turned off by default, and you have to contact Salesforce to enable it.

Changing your mind costs you the default

Models change. Know what a change does to access.

Master-detail to lookup. “Converting a master-detail relationship to a lookup for a custom object on the ‘detail’ side, changes the organization-wide default for the object to public read/write” (Considerations for Object Relationships). Read that twice. The day you convert, every record of that object is open to everyone who has the object. Plan the new default and the sharing it needs before the conversion, and set it right after.
Lookup to master-detail. You can do it only “if the lookup field in all the records contains a value,” and it “changes the organization-wide default to Controlled by Parent” (same page). The child’s own owner and sharing stop counting. Whoever sees the master sees all of its new details.

Either way, it’s a sharing change as well as a data change, so test access before and after.

Big parents

“As a best practice, don’t exceed 10,000 child records for a master-detail relationship” (Object Relationships Overview). In class I put it this way: you can get the locks at the top record on the children of a master-detail relationship. Every change to a child can wait on the same parent, and every sharing change on that parent touches all of its children. The account family behaves the same way. I call them pseudo master-details: one account with a million contacts under it is the same problem. Chapter 22 covers skew.

What an architect decides here

For every child object, master-detail or lookup, decided on the data model, with the sharing question asked: own owner, own audience, or all of the parent’s.
For every master-detail field, its Sharing Setting: Read Only or Read/Write on the master to change the details.
For every junction object, which master is primary, and what access each master needs.
For the account family, which children are Controlled by Parent (module 2).
Before any conversion, the new org-wide default and the sharing it needs, set right after.
Which parents may grow past 10,000 children, and how the model spreads them.

Beyond the exam: what AI changes. An agent that can see a master can see every detail under it, and every detail under those, in one query. Before you give an agent’s user access to a master record, list its details and their details. That’s what the agent can read. And when an agent creates details, they have no owner of their own: whoever sees the master sees what the agent wrote.

Explore

Object Relationships Overview (opens in a new tab), Salesforce Help (checked 2026-11-07)
Considerations for Object Relationships (opens in a new tab), Salesforce Help (checked 2026-11-07)
Create a Many-to-Many Object Relationship (opens in a new tab), Salesforce Help (checked 2026-11-07)