Generally no — you cannot make a standard object the detail (child) in a custom master-detail relationship. Salesforce reserves the right to be the parent on standard objects so that core functionality (ownership, sharing, lifecycle) isn’t disrupted by admin-created cascade rules. The standard objects can, however, be the master in a master-detail with a custom detail.
That said, there are a few exceptions and nuances worth knowing.
What Salesforce restricts
When you create a master-detail field on a child object pointing to a parent, the child object’s sharing model becomes “Controlled by Parent,” it loses OwnerId, and it inherits cascade delete. For standard CRM objects that are meant to have independent ownership (Accounts owned by sales, Cases owned by support, Leads in queues), removing OwnerId and forcing sharing inheritance would break the platform.
So for the major standard objects — Account, Contact, Lead, Opportunity, Case, Campaign, Task, Event, User — you cannot make them the detail of a custom object’s master-detail. The platform blocks the field creation.
You can freely create:
- A Lookup from any standard object to any other (custom or standard)
- A Master-Detail from a custom object pointing to a standard object — i.e., the standard object is the master
Standard objects that are details (out of the box)
Salesforce ships a handful of built-in master-detail relationships where standard objects are the detail side:
| Detail (child) | Master (parent) |
|---|---|
Opportunity Line Item (OpportunityLineItem) | Opportunity |
Order Product (OrderItem) | Order |
| Contract Line Item | Contract |
| Quote Line Item | Quote |
| Case Comment | Case |
| Asset (when in Asset Hierarchy) | Asset (self) |
| AttachmentRelated (legacy) | various |
These are platform-managed — you didn’t create them, Salesforce did. They exist because the child genuinely doesn’t make sense without the parent (a line item without an Opportunity is meaningless).
Workarounds when you really need cascade behavior
If you want master-detail-style behavior with a standard object on the child side, here are your options:
1. Use a Lookup with “Delete this record also”
On a Lookup field, choose the delete behavior “Delete this record also” (available when the lookup is required, with restrictions on object combinations). This gives you cascade-delete without the full master-detail treatment.
You don’t get roll-up summaries on the parent, but you do get the cascade.
2. Use a trigger to cascade
A before delete trigger on the parent object can manually delete the related standard children. Use this when the delete-behavior option isn’t available for your specific object pair.
3. Reconsider the data model
If you find yourself wanting Account → Custom Object as master-detail (so you can roll up), and the children must be Accounts themselves, the model is probably wrong. Look at:
- Inverting the relationship — custom object pointing to Account as detail (which is allowed, since custom can be detail)
- Using DLRS or trigger-based rollups on the existing lookup
- Using the standard Account Hierarchy (
ParentId) and built-in hierarchy reports
Common interview gotcha
Q: “Why can’t I make Account the child of a custom Project__c?”
A: Because Salesforce protects standard objects from losing their OwnerId, sharing model, and independent lifecycle. If Account became the detail of Project__c, then:
- Account would lose OwnerId
- Account’s sharing would be controlled by Project__c
- Deleting a Project__c would cascade-delete all its Accounts (catastrophic)
That’s why the relationship has to go the other way (Project__c as detail of Account) or remain a Lookup.
The full rule
Standard objects can be the master in any master-detail relationship with a custom detail. They generally cannot be the detail of any user-created master-detail. Built-in standard-as-detail relationships (Opportunity Line Item, Order Product, etc.) are managed by the platform itself.
Allowed combinations summary
| Master | Detail | Allowed? |
|---|---|---|
| Standard | Custom | Yes (most common pattern) |
| Custom | Custom | Yes |
| Custom | Standard | No (except built-in like OLI) |
| Standard | Standard | Only built-in (Opportunity → OLI, Order → OrderItem, etc.) |
| External | Anything | No (external uses external/indirect lookup, not M-D) |
Practical takeaway
Design relationships top-down: identify what the master is, then make custom children. If you find yourself needing a standard object as a detail, you’re almost always solving the wrong problem — step back and rethink the model.
Verified against: Salesforce Help — Master-Detail Relationship Considerations. Last reviewed 2026-05-17.