ExamFinch.com My Study

Study guide

3.2 Relationship Types & Implications

Practice this exam

Salesforce Certified Platform Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy

2 Platform Fundamentals

2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations

3 Data Modeling & Schema

3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development

4 Platform Data Features

4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries

5 Declarative Process Automation

5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools

6 Apex Language Basics

6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns

7 SOQL, SOSL & DML

7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries

8 Apex Triggers & Order of Execution

8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control

9 Asynchronous Apex

9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration

10 Security, Events & Schema Access

10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)

11 Visualforce

11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience

12 Lightning Components

12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events

13 UI Composition & Apex Integration Patterns

13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce

14 Apex Testing

14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences

15 Debugging & Developer Tools

15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy

16 Deployment & Release

16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance

3.2 Relationship Types & Implications

Key Takeaways Explain This Topic AI

Lookup relationships are loosely coupled; master-detail is tightly coupled with cascade delete, inherited sharing, and roll-up summaries on the master

Many-to-many requires a junction object with two master-detail (or sometimes lookup) relationships to the parents

Hierarchical relationships are a special self-lookup on User; external and indirect lookups connect to external objects

Relationship choice drives record access, ownership, reparenting, related lists, and parent-child SOQL shape

  • Reparenting is allowed on lookups by default and is controlled for master-detail via Allow reparenting
  • Last updated: August 2026

3.2 Relationship Types & Implications

Quick Answer: Choose lookup for optional or loosely coupled parents, master-detail when the child cannot exist without the parent and you need cascade delete, inherited security, and roll-up summaries, and a junction object for many-to-many. External and indirect lookups reach external objects ; hierarchical is a special self-relationship on User.

Relationship design is one of the highest-yield data modeling topics on Platform Developer I. The same business “link” can be modeled several ways; the platform enforces very different behavior for each.

Lookup Relationships

A lookup creates an optional (or optionally required) foreign-key style link from a child to a parent.

Characteristics:

  • Child can usually exist without a parent if the lookup is not marked required
  • Parent and child can have independent owners and sharing

Deleting the parent does not cascade-delete children by default (you can configure clear vs restrict-style behaviors depending on field settings and object type; know the exam framing: lookups are loosely coupled)

No roll-up summary fields on pure lookup parents (use Flow, Apex, or declarative workarounds)

Related lists appear on the parent; the child stores the parent Id in a field ending in __c (custom) with relationship navigation via __r

When to use: Related but independent records (for example, optional related Account on a custom Project, or linking Case to a custom Asset when the asset is not a strict parent).

Master-Detail Relationships

A master-detail relationship tightly couples child to parent.

Characteristics:

  • Child requires a parent (detail cannot be orphaned)
  • Cascade delete: deleting the master deletes detail records

Inherited sharing: detail access is controlled by the master’s sharing (detail does not have independent OWD in the usual master-detail sense)

Detail records typically do not have their own owner independent of the master (ownership follows the master model)

  • Master can define roll-up summary fields (COUNT, SUM, MIN, MAX) over detail records
  • A custom object can have up to two master-detail relationships (the foundation of many junction designs)

When to use: True parent-child lifecycles—Invoice Lines under Invoice, Expense Items under Expense Report—where lines should not survive the parent and should roll up totals.

  • Dimension Lookup Master-Detail
  • Coupling Loose Tight
  • Parent required Optional unless marked required Always required
  • Cascade delete Not the default tight cascade model Yes—detail deleted with master
  • Security Independent Inherits from master
  • Roll-up summaries No (native) Yes on master
  • Ownership Child can own independently Controlled with master
  • Many-to-Many (Junction Objects)

Salesforce has no first-class “M:N field.” You model many-to-many with a junction object that has two relationships to the parent objects—classically two master-detail relationships (for example, Job_Application__c junction between Candidate__c and Position__c ).

Implications:

Each junction row represents one association pair (plus association attributes: status, applied date)

With two master-details, junction sharing and cascade behavior follow master-detail rules from both parents (understand deletion impact)

  • Related lists on each parent show related counterparts through the junction
  • SOQL often queries the junction and navigates both __r parents, or uses subqueries from either parent

Sometimes architects use lookup-based junctions when independent ownership or optional parents are required—but then you lose native roll-ups and cascade semantics. Exam scenarios that stress “must be deleted with parent” and “roll up count of related X” point to master-detail junctions.

Hierarchical Relationships

A hierarchical relationship is a special lookup limited to the User object (self-relationship). It models manager hierarchies and similar user trees without using a generic self-lookup pattern available on all objects. For custom objects, self-relationships are ordinary lookups to the same object (for example, parent Account uses the standard Account hierarchy; custom Team__c might look up another Team__c ).

External Lookup and Indirect Lookup

When Salesforce Connect exposes external objects (data lives outside Salesforce):

External lookup: Child (Salesforce or external) relates to a parent external object using the external object’s external ID-style key

Indirect lookup: External child object relates to a standard/custom Salesforce parent by matching an External ID field on the parent

These relationships power hybrid architectures. They do not behave like in-org master-detail for cascade delete and roll-ups; treat external data as loosely coupled and latency-sensitive. Exam items often test whether you recognize that external/indirect lookups are the correct link type when one side is an external object.

Record Access, UI, and Related Lists

Relationship type shapes the user experience:

Related lists on parent layouts show child records; master-detail and lookup both support related lists, but security may hide children the user cannot see

Master-detail children appear only when the user can access the master (inherited model)

Lookup children may be visible based on their own sharing even if parent visibility differs (and vice versa), which can surprise admins

  • Detail pages show lookup fields as clickable links to parents
  • Apex and SOQL Implications
  • Child-to-parent: SELECT Name, Account__r.Name FROM Invoice__c
  • Parent-to-child subquery: SELECT Name, (SELECT Amount__c FROM Invoice_Lines__r) FROM Invoice__c

Relationship API names (plural child relationship names) are set when the relationship field is created—wrong names break subqueries

Master-detail cascades mean Apex deletes on parents can remove large child sets—watch governor limits and recursive triggers

  • Inserting detail records requires parent Id; order of insert in tests and loaders matters
  • Reparenting Rules

Reparenting means changing a child’s parent pointer after insert.

Lookup: Generally allowed (unless the field is restricted); child can move between parents

Master-detail: Reparenting is disabled by default on the relationship; admins can enable Allow reparenting on the master-detail field when the business must move details between masters

Exam scenarios that say “child must always stay with the original parent” align with master-detail without reparenting; “reassign line items to another order” needs lookup or master-detail with reparenting enabled.

  • Choosing Quickly Under Exam Pressure
  • Optional parent or independent security → lookup
  • Required parent, cascade delete, roll-ups, inherit sharing → master-detail
  • Many parents to many children → junction object
  • User manager chain → hierarchical (User)
  • Parent or child is external object → external / indirect lookup

Get the relationship wrong and every later choice—roll-ups, sharing, Apex, imports—gets harder. Get it right and the platform does much of the work for you.