Relationship
A Relationship in Salesforce is the data-model connection between two objects established through a relationship field (Lookup, Master-Detail, Hierarchical, or External Lookup).
Definition
A Relationship in Salesforce is the data-model connection between two objects established through a relationship field (Lookup, Master-Detail, Hierarchical, or External Lookup). The relationship lets records on one object reference records on another, enabling the platform to navigate between related records, roll up data, enforce referential integrity, and inherit sharing where applicable. Relationships are fundamental to every Salesforce data model because almost no business entity exists in isolation: Accounts have Contacts, Contacts have Cases, Opportunities have Products, Orders have Order Products.
Salesforce supports several relationship types, each with its own semantics. Lookup is the loose relationship where the child references the parent but neither cascades nor enforces tight coupling. Master-Detail is the tight relationship where the child cannot exist without the parent, cascades on delete, and inherits the parent's sharing. Hierarchical is a self-referencing relationship used primarily on the User object for the manager hierarchy. External Lookup connects Salesforce objects to External Objects (typically representing data in an external system via Salesforce Connect). Choosing the right relationship type for each connection is one of the most consequential data-model decisions.
The relationship types and when to use each
Lookup relationship
Lookup is the most flexible and most commonly used relationship type. The child object has a Lookup field pointing at the parent object. The child can exist without the parent (the Lookup is optional), and deleting the parent does not delete the child by default (although a cascade-delete option can be enabled at the field level). Lookup is the right choice for most cross-object relationships where the child has independent meaning: Contact looks up Account (a contact remains relevant even if temporarily detached from an account), Case looks up Contact (a case can exist for an anonymous customer), custom Project__c looks up Account. Lookups support standard related lists, cross-object formulas, and reporting joins.
Master-Detail relationship
Master-Detail establishes a tight parent-child connection where the child cannot exist without the parent. Deleting the parent cascades to delete every child. The child inherits the parent's sharing automatically, which means you cannot configure separate sharing rules on the child. The child also inherits the parent's owner (the child does not have its own Owner field) and supports Roll-Up Summary fields on the parent. Master-Detail is the right choice when the child is conceptually part of the parent: Opportunity Product is a line item on an Opportunity, Quote Line Item belongs to a Quote, custom Inspection Detail__c belongs to an Inspection__c. The cascade behavior and sharing inheritance are usually what you want for these scenarios.
Hierarchical relationship
Hierarchical is a special relationship type available only on the User object. It is a Lookup to User and represents the org's reporting hierarchy (the Manager field on each user record). The hierarchical relationship is what Salesforce uses for sharing-by-role-hierarchy calculations: when a record is owned by a user, the user's manager (via the Hierarchical relationship) automatically gets access. Hierarchical relationships are not user-creatable on other objects, only on User. The relationship is recursive (a user can be a manager of users who themselves are managers), and the platform handles the recursive traversal automatically.
Many-to-Many relationship via junction object
Many-to-many relationships are implemented with a junction object: a custom object with two Master-Detail relationships, one to each end of the many-to-many. Account-to-Contact is conceptually many-to-many (a contact can be associated with multiple accounts) but is implemented through the AccountContactRelation junction object. Opportunity-to-Contact uses OpportunityContactRole as the junction. Custom many-to-many relationships (Project__c to Team_Member__c through Project_Team_Member__c) follow the same pattern. The junction object's two Master-Detail fields make it tightly coupled to both ends, and deleting either end cascades to the junction.
External Lookup and indirect Lookup
External Lookup connects a Salesforce object to an External Object (a metadata-defined virtual object that represents data living outside Salesforce, served by Salesforce Connect). The External Lookup references the external object's external ID rather than a Salesforce 15- or 18-character ID. Indirect Lookup goes the other direction: an External Object record references a Salesforce object through a custom field's external ID value. Both relationship types enable hybrid scenarios where some data lives in Salesforce and some lives in an external system (ERP, mainframe, third-party CRM), but the user experiences them as a unified data model.
Self-relationships and recursive structures
Some objects have Lookup relationships to themselves (a Contact lookup to another Contact for a Spouse field, an Account lookup to a Parent Account for the Account Hierarchy). Self-relationships enable recursive structures and parent-child hierarchies within a single object. The Account Hierarchy is the most common example, supporting multi-level company structures (subsidiaries, divisions, departments). Self-relationships are subject to the standard Lookup rules; Salesforce does not enforce non-cyclical structure, so it is possible (though usually unintentional) to create a cycle. Validation rules or trigger logic should prevent cycles on objects where it matters.
Lookup filters and reparenting
Lookup fields support filters that restrict which parent records the user can select. A Project lookup might filter to only Accounts in Active status, or only Contacts in a specific Country. Lookup filters are evaluated at record-edit time and run on the server. For Master-Detail relationships, the platform supports reparenting (changing the parent of an existing child record) only if the relationship explicitly allows it. By default, Master-Detail relationships are not reparentable; the child's parent cannot be changed after creation. Lookup relationships are always reparentable. The reparenting behavior is something to consider when choosing between Master-Detail and Lookup for a new relationship.
Relationships and reporting
Relationships shape what reports can do. The standard report types include the parent-child relationships defined on the underlying objects, so a report on Opportunities can include fields from the related Account, the related Account's parent Account, the related Account's Owner, and so on, traversing up to five levels of lookup or master-detail relationships. Reports also support inner-join and outer-join behavior between parent and child objects: with-related-list reports (Accounts with Opportunities) require the join, with-or-without-related-list reports (Accounts with or without Opportunities) make the join optional. Custom report types let admins build exactly the combinations the business needs, including which relationships to traverse and which fields to expose. Understanding how relationships affect reporting is essential because most reporting questions are really cross-object questions, and the relationships determine whether the question can even be expressed in a standard report. When a stakeholder asks for a report that does not seem possible, the answer is often that the underlying relationship is missing or misconfigured, and the data model needs adjustment before the report can be built. Smart data-model designers anticipate reporting needs during initial design rather than retrofitting relationships later.
Create the right relationship between two objects
Choosing and configuring the right relationship between two objects is one of the most common data-model decisions for Salesforce admins. The walkthrough below covers the standard sequence for designing and creating a relationship, with guidance for choosing among Lookup, Master-Detail, and the alternatives.
- Decide which relationship type fits the use case
Answer four questions about the relationship: can the child exist without the parent (yes implies Lookup, no implies Master-Detail), should deleting the parent delete the child (yes implies Master-Detail), should the child inherit the parent's sharing (yes implies Master-Detail), and does the child need its own Owner field (yes implies Lookup). For most scenarios, Lookup is the right default; choose Master-Detail only when the child is genuinely a sub-component of the parent.
- Create the relationship field in Object Manager
From Setup, open the child object in Object Manager. Click Fields and Relationships and then New. Choose the field type (Lookup Relationship or Master-Detail Relationship). Configure the field: label, API name, parent object, child relationship name (used in SOQL queries), and any field-specific options (required at form level, cascade delete for Lookup, reparenting allowed for Master-Detail). Add a description that explains the business meaning. Save and assign the field to the relevant page layouts.
- Configure lookup filters and validation
If the relationship should restrict which parent records can be selected, add a Lookup Filter that constrains the parent picker. The filter can reference parent record fields, runtime user fields, or custom logic. Add any validation rules that should fire when the relationship is set or changed. Test the configuration in a sandbox: try to create a child record with various parent values, including invalid ones, and confirm the filter and validation behave correctly.
- Update reports, page layouts, and automation
Add the new relationship to relevant report types so reports can use the cross-object data. Update child record page layouts to expose the parent record's information prominently. Update parent page layouts to add the related list showing the new child object. Audit existing automation (Flow, Apex triggers) for places where the new relationship should drive behavior, and update accordingly. Test end-to-end in sandbox before deploying to production.
Both objects must exist before the relationship can be created. Either standard or custom objects work.
The unique field identifier on the child object that holds the parent reference.
Lookup, Master-Detail, External Lookup, or Indirect Lookup, based on the use case.
The SOQL traversal name used to query children from the parent.
Required to create relationship fields in Setup.
- Master-Detail is hard to convert to Lookup after records exist. Choose Lookup as the default unless you specifically need cascade-delete and sharing inheritance.
- Master-Detail relationships do not have their own Owner field; the child inherits the parent's owner. This sometimes surprises admins coming from other databases.
- Roll-Up Summary fields only work on Master-Detail relationships, not Lookup. If you need cross-object aggregation on a Lookup, you need an Apex trigger or a Flow to maintain the rolled-up field.
- Lookup Filters run on every save and lookup. Complex filter logic can slow down record creation; keep filters as simple as possible.
- Many-to-many relationships through junction objects require a custom object with two Master-Detail fields. Both ends have full cascade-delete impact on the junction.
Trust & references
Straight from the source - Salesforce's reference material on Relationship.
- RelationshipsSalesforce Help
- Create Relationship FieldsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Relationship in Salesforce?
Q2. What types exist?
Q3. How do you choose the type?
Discussion
Loading discussion…