Controlled by Parent Access on Detail Records
5 minutes
5 Questions
In Salesforce, 'Controlled by Parent' is an organization-wide default (OWD) sharing setting that governs access to detail records in a master-detail relationship. When an object is the detail (child) side of a master-detail relationship, its sharing settings cannot be set independently; instead, access is automatically inherited from the master (parent) record. This means that a user's ability to view, edit, or delete a detail record is determined entirely by their access to the associated parent record. For example, if a custom object 'Invoice Line Item' is the detail of 'Invoice', a user who has read-only access to a specific Invoice will also have read-only access to all its Invoice Line Items. Likewise, if the user can edit the Invoice, they can edit its line items. Detail records in master-detail relationships do not have their own Owner field, so ownership-based sharing rules, manual sharing, and role hierarchy evaluations are applied at the parent level and cascade down. This simplifies security administration because administrators only need to manage sharing on the parent object, ensuring consistency and reducing the risk of misaligned permissions. Note that 'Controlled by Parent' can also be applied to certain standard objects such as Contacts, Orders, and Assets, where the OWD can optionally be set to inherit from the Account. In those cases, choosing 'Controlled by Parent' removes the ability to set an independent OWD or create sharing rules for that child object. For Platform Administrator II candidates, it is important to understand that while object-level permissions (CRUD) on the detail object's profile or permission set still apply, record-level visibility is dictated by the parent. If a user lacks access to the parent, they cannot access the child record even if their profile grants Read on the child object. This behavior is a key consideration when designing data models and sharing architectures that must balance security with usability.
Controlled by Parent Access on Detail Records: A Complete Guide for the Salesforce Advanced Administrator Exam
Why This Topic Matters
Record-level security is one of the most heavily tested areas of the Salesforce Advanced Administrator exam, and the Controlled by Parent setting sits right at the intersection of data modeling and security. When a relationship is master-detail, the detail record does not have its own independent sharing model; it inherits access from the master record. Misunderstanding this leads to real-world problems such as users who cannot edit child records even though sharing rules appear correct, administrators trying to create sharing rules that are not available, or designs that accidentally expose or lock down data. In the exam, this concept appears in scenario questions about why a user can or cannot see or edit a related record, how to fix access to child records, when to use master-detail versus lookup, and how standard objects such as Contacts, Orders, Assets, and Activities behave when set to Controlled by Parent.
What Is Controlled by Parent?
Controlled by Parent is an Organization-Wide Default (OWD) sharing setting. It means that a record's visibility and edit access are determined entirely by the user's access to its parent (master) record. If a user can read the parent, they can read the child. If a user can edit the parent, they can edit the child (subject to the master-detail field's Sharing Setting and object permissions). The child has no independent sharing of its own.
There are two situations where you encounter Controlled by Parent:
1. Custom objects on the detail side of a master-detail relationship. When you create a master-detail field on a custom object, Salesforce automatically sets that object's OWD to Controlled by Parent, and you cannot change it while the master-detail relationship exists.
2. Certain standard objects where Controlled by Parent is an optional OWD choice. These include Contacts (controlled by Account), Orders (controlled by Account), Assets (controlled by Account), Activities such as Tasks and Events (controlled by the related record; this is the default for Activities), Campaign Members (Controlled by Campaign), and Individuals (controlled by Contact or Lead). For these objects, an administrator chooses between Private, Public Read Only, Public Read/Write, and Controlled by Parent.
How It Works on Detail Records
1. No independent owner. Detail records in a master-detail relationship do not have their own Owner field. Ownership, role hierarchy access, and sharing are all inherited from the master record. Because there is no owner, there is no owner-based sharing rule, no manual Share button, and no role hierarchy grant specific to the detail object.
2. No sharing rules, manual sharing, or Apex managed sharing for the detail object. Because access flows from the parent, Salesforce removes the detail object from the Sharing Rules section and does not create a Share object for it. If you need to open up access to detail records, you must open access to the master records, or convert the relationship to a lookup.
3. The Sharing Setting on the master-detail field. When you create or edit a master-detail field, you choose a Sharing Setting:
- Read/Write: Users need at least Read/Write access to the master record to create, edit, or delete related detail records. This is the default.
- Read Only: Users need only Read access to the master record to create, edit, or delete related detail records.
This setting is a frequent source of exam scenarios. If users can see child records but cannot create or edit them, and they have only read access to the parent, changing this setting to Read Only (meaning read access on the parent is sufficient) resolves the issue without widening parent access.
4. Object permissions still apply. Controlled by Parent governs record-level access only. The user's profile or permission sets must still grant Create, Read, Edit, or Delete on the detail object. A user with Edit access to the parent record but no Edit permission on the child object cannot edit child records. Conversely, object permissions never override Controlled by Parent; a user with Modify All on the child but no access to the parent will still not see the child record unless they have View All or Modify All on the parent or similar elevated access.
5. Cascade behavior. Deleting a master record deletes its detail records. Detail records cannot exist without a master (the master-detail field is always required). Roll-up summary fields are only possible from detail to master. These behaviors reinforce that the detail record is a dependent part of the parent.
6. Junction objects (two master-detail relationships). For a many-to-many design, the junction object has two masters. Access to a junction record requires appropriate access to both parent records, with the level required on each determined by that relationship's Sharing Setting. The primary (first) master-detail relationship determines look and feel, role hierarchy, and inherited ownership. Deleting either master deletes the junction record.
7. Internal and external default access. When an object is Controlled by Parent, both Default Internal Access and Default External Access are Controlled by Parent; you cannot set them independently.
Controlled by Parent on Standard Objects: Key Behaviors
Contacts. Setting Contact OWD to Controlled by Parent means that a user's access to a Contact mirrors their access to the related Account. Consequences include: contact sharing rules are removed and cannot be created; manual sharing of contacts is not available; the Contact Access option disappears from role settings and account teams; and contacts with no account (private contacts) are visible only to their owner, users above the owner in the role hierarchy, and users with View All or Modify All permissions. Also remember that the Contact OWD cannot be more permissive than the Account OWD.
Orders and Assets. These behave similarly, with access controlled by the parent Account. Sharing rules for these objects are unavailable when set to Controlled by Parent.
Activities. Tasks and Events default to Controlled by Parent. A user who can see the related record (the Related To or Name record) can see the activity; a user who can edit the related record can edit the activity. Setting Activities to Private restricts them to the assigned user and those above in the role hierarchy.
Campaign Members. Access is Controlled by Campaign; if a user can view a campaign, they can view its members, and editing depends on campaign access plus the Marketing User checkbox and object permissions.
Design Decisions: Master-Detail Versus Lookup
Choose master-detail when the child should not exist without the parent, when roll-up summary fields are required, and when access to the child should always match access to the parent. Choose lookup when the child needs its own owner, its own sharing rules, manual sharing, or an independent OWD. Converting master-detail to lookup gives the child an Owner field and independent OWD; converting lookup to master-detail requires that every existing record have a populated parent value and that the OWD will become Controlled by Parent.
Troubleshooting Flow for Exam Scenarios
When a question describes a user who cannot see or edit a detail record, work through this sequence:
1. Is the relationship master-detail? If so, the OWD is Controlled by Parent and sharing rules on the child are not an option.
2. Does the user have access to the parent record (through OWD, role hierarchy, sharing rules, teams, or manual sharing)? If not, grant access at the parent level.
3. Does the user need to edit? Check the master-detail field's Sharing Setting. If it is Read/Write and the user only has Read on the parent, either grant edit on the parent or change the Sharing Setting to Read Only.
4. Does the user's profile or permission set include the needed object permissions on the child object?
5. Are there field-level security or page layout restrictions that are being confused with record access?
Exam Tips: Answering Questions on Controlled by Parent Access on Detail Records
Tip 1: Spot the master-detail clue. If the scenario mentions roll-up summary fields, cascade delete, or a required parent, the relationship is master-detail and the child OWD is Controlled by Parent. Any answer suggesting a sharing rule, manual sharing, or owner-based sharing on the detail object is wrong.
Tip 2: Remember the Sharing Setting on the field. When users can view but not create or edit child records, the fastest and least disruptive fix is usually to set the master-detail field's Sharing Setting to Read Only (requires only Read on the master). Do not confuse this with making the child read-only; the wording means read access to the parent is enough to edit the child.
Tip 3: Separate record access from object permissions. Controlled by Parent is about which records a user can reach. Profiles and permission sets are about what actions a user can take on the object. Questions often combine both; a correct answer must satisfy both layers.
Tip 4: Know the standard objects that offer Controlled by Parent. Contacts, Orders, Assets, Activities, Campaign Members, and Individuals. Opportunities, Cases, Leads, and Accounts do not offer this option.
Tip 5: Watch for Contact-specific consequences. Setting Contact OWD to Controlled by Parent removes contact sharing rules, removes role-based Contact Access settings, and makes private contacts (no account) effectively private to the owner and role hierarchy. If a scenario needs contact sharing rules, Contact OWD cannot be Controlled by Parent.
Tip 6: When independent sharing on the child is required, think lookup. If the business needs different users to see a child than those who see the parent, or needs an owner on the child, the correct design answer is a lookup relationship with its own OWD and sharing rules, not master-detail.
Tip 7: Junction objects need access to both parents. If a question involves a many-to-many design, remember that access to the junction record depends on access to both master records, and the primary relationship drives role hierarchy and ownership behavior.
Tip 8: Eliminate distractors that overcomplicate. Answers involving Apex managed sharing, custom permission checks, or complex automation for detail records are usually wrong because Controlled by Parent already handles access and because detail objects cannot have sharing records. Prefer declarative, parent-level solutions.
Tip 9: Remember what View All and Modify All do. These object-level permissions bypass sharing, including Controlled by Parent, so a user with Modify All on the parent object can reach all child records regardless of inherited sharing. Use this knowledge to evaluate answers about administrators or power users.
Tip 10: Read the question for the exact failure. Cannot see versus cannot edit versus cannot create leads to different answers: visibility points to parent access; editing points to the Sharing Setting and Edit permission; creating points to Create permission on the child plus the appropriate access on the parent. Matching the symptom to the layer is the key to selecting the correct option quickly.
Summary
Controlled by Parent means a detail record borrows its sharing from its master record: no owner, no sharing rules, no manual sharing, and access that rises and falls with the parent. The master-detail field's Sharing Setting determines whether Read or Read/Write on the parent is needed to modify the child, and object permissions still apply on top. Certain standard objects, most notably Contacts and Activities, can also be set to Controlled by Parent with specific side effects. For the exam, identify the relationship type, trace access through the parent, check the Sharing Setting and object permissions, and recognize when a lookup relationship is the only way to achieve independent sharing on the child.
Record-level security is one of the most heavily tested areas of the Salesforce Advanced Administrator exam, and the Controlled by Parent setting sits right at the intersection of data modeling and security. When a relationship is master-detail, the detail record does not have its own independent sharing model; it inherits access from the master record. Misunderstanding this leads to real-world problems such as users who cannot edit child records even though sharing rules appear correct, administrators trying to create sharing rules that are not available, or designs that accidentally expose or lock down data. In the exam, this concept appears in scenario questions about why a user can or cannot see or edit a related record, how to fix access to child records, when to use master-detail versus lookup, and how standard objects such as Contacts, Orders, Assets, and Activities behave when set to Controlled by Parent.
What Is Controlled by Parent?
Controlled by Parent is an Organization-Wide Default (OWD) sharing setting. It means that a record's visibility and edit access are determined entirely by the user's access to its parent (master) record. If a user can read the parent, they can read the child. If a user can edit the parent, they can edit the child (subject to the master-detail field's Sharing Setting and object permissions). The child has no independent sharing of its own.
There are two situations where you encounter Controlled by Parent:
1. Custom objects on the detail side of a master-detail relationship. When you create a master-detail field on a custom object, Salesforce automatically sets that object's OWD to Controlled by Parent, and you cannot change it while the master-detail relationship exists.
2. Certain standard objects where Controlled by Parent is an optional OWD choice. These include Contacts (controlled by Account), Orders (controlled by Account), Assets (controlled by Account), Activities such as Tasks and Events (controlled by the related record; this is the default for Activities), Campaign Members (Controlled by Campaign), and Individuals (controlled by Contact or Lead). For these objects, an administrator chooses between Private, Public Read Only, Public Read/Write, and Controlled by Parent.
How It Works on Detail Records
1. No independent owner. Detail records in a master-detail relationship do not have their own Owner field. Ownership, role hierarchy access, and sharing are all inherited from the master record. Because there is no owner, there is no owner-based sharing rule, no manual Share button, and no role hierarchy grant specific to the detail object.
2. No sharing rules, manual sharing, or Apex managed sharing for the detail object. Because access flows from the parent, Salesforce removes the detail object from the Sharing Rules section and does not create a Share object for it. If you need to open up access to detail records, you must open access to the master records, or convert the relationship to a lookup.
3. The Sharing Setting on the master-detail field. When you create or edit a master-detail field, you choose a Sharing Setting:
- Read/Write: Users need at least Read/Write access to the master record to create, edit, or delete related detail records. This is the default.
- Read Only: Users need only Read access to the master record to create, edit, or delete related detail records.
This setting is a frequent source of exam scenarios. If users can see child records but cannot create or edit them, and they have only read access to the parent, changing this setting to Read Only (meaning read access on the parent is sufficient) resolves the issue without widening parent access.
4. Object permissions still apply. Controlled by Parent governs record-level access only. The user's profile or permission sets must still grant Create, Read, Edit, or Delete on the detail object. A user with Edit access to the parent record but no Edit permission on the child object cannot edit child records. Conversely, object permissions never override Controlled by Parent; a user with Modify All on the child but no access to the parent will still not see the child record unless they have View All or Modify All on the parent or similar elevated access.
5. Cascade behavior. Deleting a master record deletes its detail records. Detail records cannot exist without a master (the master-detail field is always required). Roll-up summary fields are only possible from detail to master. These behaviors reinforce that the detail record is a dependent part of the parent.
6. Junction objects (two master-detail relationships). For a many-to-many design, the junction object has two masters. Access to a junction record requires appropriate access to both parent records, with the level required on each determined by that relationship's Sharing Setting. The primary (first) master-detail relationship determines look and feel, role hierarchy, and inherited ownership. Deleting either master deletes the junction record.
7. Internal and external default access. When an object is Controlled by Parent, both Default Internal Access and Default External Access are Controlled by Parent; you cannot set them independently.
Controlled by Parent on Standard Objects: Key Behaviors
Contacts. Setting Contact OWD to Controlled by Parent means that a user's access to a Contact mirrors their access to the related Account. Consequences include: contact sharing rules are removed and cannot be created; manual sharing of contacts is not available; the Contact Access option disappears from role settings and account teams; and contacts with no account (private contacts) are visible only to their owner, users above the owner in the role hierarchy, and users with View All or Modify All permissions. Also remember that the Contact OWD cannot be more permissive than the Account OWD.
Orders and Assets. These behave similarly, with access controlled by the parent Account. Sharing rules for these objects are unavailable when set to Controlled by Parent.
Activities. Tasks and Events default to Controlled by Parent. A user who can see the related record (the Related To or Name record) can see the activity; a user who can edit the related record can edit the activity. Setting Activities to Private restricts them to the assigned user and those above in the role hierarchy.
Campaign Members. Access is Controlled by Campaign; if a user can view a campaign, they can view its members, and editing depends on campaign access plus the Marketing User checkbox and object permissions.
Design Decisions: Master-Detail Versus Lookup
Choose master-detail when the child should not exist without the parent, when roll-up summary fields are required, and when access to the child should always match access to the parent. Choose lookup when the child needs its own owner, its own sharing rules, manual sharing, or an independent OWD. Converting master-detail to lookup gives the child an Owner field and independent OWD; converting lookup to master-detail requires that every existing record have a populated parent value and that the OWD will become Controlled by Parent.
Troubleshooting Flow for Exam Scenarios
When a question describes a user who cannot see or edit a detail record, work through this sequence:
1. Is the relationship master-detail? If so, the OWD is Controlled by Parent and sharing rules on the child are not an option.
2. Does the user have access to the parent record (through OWD, role hierarchy, sharing rules, teams, or manual sharing)? If not, grant access at the parent level.
3. Does the user need to edit? Check the master-detail field's Sharing Setting. If it is Read/Write and the user only has Read on the parent, either grant edit on the parent or change the Sharing Setting to Read Only.
4. Does the user's profile or permission set include the needed object permissions on the child object?
5. Are there field-level security or page layout restrictions that are being confused with record access?
Exam Tips: Answering Questions on Controlled by Parent Access on Detail Records
Tip 1: Spot the master-detail clue. If the scenario mentions roll-up summary fields, cascade delete, or a required parent, the relationship is master-detail and the child OWD is Controlled by Parent. Any answer suggesting a sharing rule, manual sharing, or owner-based sharing on the detail object is wrong.
Tip 2: Remember the Sharing Setting on the field. When users can view but not create or edit child records, the fastest and least disruptive fix is usually to set the master-detail field's Sharing Setting to Read Only (requires only Read on the master). Do not confuse this with making the child read-only; the wording means read access to the parent is enough to edit the child.
Tip 3: Separate record access from object permissions. Controlled by Parent is about which records a user can reach. Profiles and permission sets are about what actions a user can take on the object. Questions often combine both; a correct answer must satisfy both layers.
Tip 4: Know the standard objects that offer Controlled by Parent. Contacts, Orders, Assets, Activities, Campaign Members, and Individuals. Opportunities, Cases, Leads, and Accounts do not offer this option.
Tip 5: Watch for Contact-specific consequences. Setting Contact OWD to Controlled by Parent removes contact sharing rules, removes role-based Contact Access settings, and makes private contacts (no account) effectively private to the owner and role hierarchy. If a scenario needs contact sharing rules, Contact OWD cannot be Controlled by Parent.
Tip 6: When independent sharing on the child is required, think lookup. If the business needs different users to see a child than those who see the parent, or needs an owner on the child, the correct design answer is a lookup relationship with its own OWD and sharing rules, not master-detail.
Tip 7: Junction objects need access to both parents. If a question involves a many-to-many design, remember that access to the junction record depends on access to both master records, and the primary relationship drives role hierarchy and ownership behavior.
Tip 8: Eliminate distractors that overcomplicate. Answers involving Apex managed sharing, custom permission checks, or complex automation for detail records are usually wrong because Controlled by Parent already handles access and because detail objects cannot have sharing records. Prefer declarative, parent-level solutions.
Tip 9: Remember what View All and Modify All do. These object-level permissions bypass sharing, including Controlled by Parent, so a user with Modify All on the parent object can reach all child records regardless of inherited sharing. Use this knowledge to evaluate answers about administrators or power users.
Tip 10: Read the question for the exact failure. Cannot see versus cannot edit versus cannot create leads to different answers: visibility points to parent access; editing points to the Sharing Setting and Edit permission; creating points to Create permission on the child plus the appropriate access on the parent. Matching the symptom to the layer is the key to selecting the correct option quickly.
Summary
Controlled by Parent means a detail record borrows its sharing from its master record: no owner, no sharing rules, no manual sharing, and access that rises and falls with the parent. The master-detail field's Sharing Setting determines whether Read or Read/Write on the parent is needed to modify the child, and object permissions still apply on top. Certain standard objects, most notably Contacts and Activities, can also be set to Controlled by Parent with specific side effects. For the exam, identify the relationship type, trace access through the parent, check the Sharing Setting and object permissions, and recognize when a lookup relationship is the only way to achieve independent sharing on the child.
Test mode:
Admin II - Controlled by Parent Access on Detail Records Example Questions
Test your knowledge of Controlled by Parent Access on Detail Records
Question 1
When a detail object's organization-wide default is set to Controlled by Parent, which statement best describes how a user's access to a detail record is determined?
Question 2
Cloud Kicks is designing a custom Invoice Line object related to a custom Invoice object. Invoice is set to Private. Users who can see an invoice, including finance users given access through manual sharing, must see all of that invoice's lines. Users must not see lines on invoices they cannot access. Each invoice must also show a total of its line amounts. The administrator is reviewing four proposed designs. Which recommendation best meets every requirement?
Question 3
Universal Containers has a Job Application object on the detail side of a master-detail relationship with Position. The org-wide default for Position is Private, and hiring managers own the Position records. Recruiters in the East region must view the job applications for East positions only. Applications for other regions must stay hidden from them. What should the administrator do?
Unlock Premium Access
Salesforce Certified Platform Administrator II
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 2973 Superior-grade Salesforce Certified Platform Administrator II practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- Admin II: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!
More Controlled by Parent Access on Detail Records questions
25 questions (total)
Other Security and Access concepts
Account Hierarchies and Business Account ModelsAccount Teams, Opportunity Teams and Manual SharingConnected App Access PoliciesContacts to Multiple AccountsCustom Profiles Versus Permission SetsDelegated AdministrationEmail Template Folder AccessEnterprise Territory Management Record AccessField-Level Security Across Profiles and Permission SetsLogin Hours, Login IP Ranges and Trusted IP RangesMulti-Factor Authentication for UsersOrganization-Wide Defaults and External Sharing ModelOwner-Based and Criteria-Based Sharing RulesPermission Set Groups and Muting Permission SetsPerson AccountsReport and Dashboard Folder AccessRestriction Rules and Scoping RulesRole Hierarchy and Grant Access Using HierarchiesSession Settings and High-Assurance SessionsSingle Sign-On with SAML and Identity ProvidersTroubleshooting Record Access with Sharing HierarchyView All, Modify All and Administrative Permissions