Developer Fundamentals PD1 · 23% of exam

Overview

23% of the exam — the "how the platform actually works" section. Multitenancy explains almost everything else on PD1 (including why governor limits exist), and data modeling/relationship traps are some of the most reliably repeated questions on the whole test.

23%Of the whole exam
2Master-Detail max per object
40Lookups max per object
50,000Data Import Wizard row cap

Exam checklist

  • Multitenancy → why governor limits exist · metadata-driven architecture · API versioning
  • All relationship types (Lookup, Master-Detail, Many-to-Many, Hierarchical, External/Indirect Lookup) · __r naming · cascade delete · reparenting
  • Field types (formula, roll-up, picklist vs multi-select, External ID + Unique, field dependencies)
  • Record Types + Page Layouts + Profile interaction · Business Processes
  • Environments: DE org vs 4 sandbox types vs Scratch Org vs Trailhead Playground
  • Declarative-vs-programmatic decision framework · Data import/export tools · Package types · API basics
Top trapsCascade delete bypasses normal delete permissions/sharing on children · Field-Level Security always overrides Page Layout visibility · External ID alone does not enforce uniqueness (need "Unique" too) · Roll-Up Summary needs Master-Detail, never Lookup · Data Import Wizard caps at 50,000 records.

Multitenancy & Platform Architecture

Foundational

Multitenancy → why governor limits exist ⭐

  • Multitenancy: one shared physical infrastructure (app servers, DB instances) serves many customer orgs ("tenants"). All tenants' data lives in shared tables, logically separated by an internal Org ID — not separate schemas/databases per customer.
  • Because compute/DB resources are shared across every tenant, Salesforce enforces strict per-transaction/per-org limits so one tenant's runaway code can't degrade performance for everyone else on the same servers.
Repeated question"Why do governor limits exist?" → this causal link (shared infrastructure → limits protect all tenants) is one of the single most repeated conceptual questions on PD1.

Metadata-driven architecture

Customizations (objects, fields, Apex, layouts, permissions) are stored as metadata, not tenant-specific compiled code baked into the core engine. Every customer runs the identical underlying application engine — customization is just data interpreted at runtime. This is why declarative changes deploy instantly, and why Salesforce can push 3 annual platform releases without breaking individual orgs' customizations.

API versioning

Every Apex class/trigger, LWC bundle, and API call is tagged with an API version. This lets Salesforce change behavior in new versions while guaranteeing backward compatibility — code saved against an older version keeps behaving exactly as it did, "pinned" to its saved version, even after platform-wide upgrades.

Data Modeling Deep Dive

High-yield

All relationship types

TypeBondCascade deleteRoll-upsRequired?
LookupLoose, independent OWD/sharingNoNoOptional
Master-DetailTight, child inherits parent's securityYes, alwaysYesRequired
Many-to-Many (junction)Via junction's 2 M-D legsYes, per legYes, per legVia the 2 M-Ds
HierarchicalSelf-referencing — User object onlyNoNoOptional
External LookupSalesforce ↔ external object, joins on external IdNoNoOptional
Indirect LookupExternal object (child) ↔ Salesforce object (parent)NoNoOptional
TrapsA junction object with Lookup+Lookup gives you neither rollups nor cascade delete — it must be Master-Detail on at least both legs. Hierarchical relationships exist only on the User object (e.g., "Manager") — don't confuse with a generic self-lookup. Max 2 Master-Detail relationships per object, even in a junction.

Relationship naming & __r

  • Every relationship field has an API field name (__c) and a Relationship Name for SOQL traversal, which gets __r appended for custom relationships (custom-to-custom AND custom-to-standard).
  • Standard relationships use fixed names without __r (e.g., Account, Owner).
  • Child-relationship subqueries on custom objects also get __r: (SELECT Id FROM Contacts__r).

Cascade delete & reparenting

  • Deleting a Master record automatically deletes all detail/subdetail records — and this bypasses normal delete permission checks on the children.
  • Master-Detail detail records cannot be reparented by default — admin must check "Allow reparenting" (custom objects only) to permit changing the parent.
  • Schema Builder: a visual drag-and-drop tool to view/create objects, fields, and relationships together — declarative only, no logic beyond field definitions.

Field Types & Behaviors

Formula vs Roll-Up Summary (recap)

  • Formula — read-only, calculated on read, traverses parent relationships up to 10 deep; cannot reach children.
  • Roll-Up Summary — parent side of Master-Detail only; COUNT/SUM/MIN/MAX with optional filter criteria; max 25 per object.

Picklist vs Multi-Select Picklist

  • Picklist — single value from a value set.
  • Multi-Select Picklist — multiple values, stored as one semicolon-delimited string; filter with INCLUDES()/EXCLUDES(), not =.

External ID + Unique — the upsert key ⭐

  • A field marked External ID identifies a record by a value from an external system.
  • Marking it also Unique enables true idempotent upsert (via Data Loader/API) keyed on that value instead of the Salesforce record Id — critical for re-running data migrations without creating duplicates.
  • Only Text, Number, and Auto Number fields can be External ID. Soft limit of ~3 External ID fields per object via UI.
TrapExternal ID alone does not enforce uniqueness — it just flags the field as an integration-matching key. You must separately check Unique to prevent duplicate values.

Field dependencies

A controlling field (picklist or checkbox) determines which values are available in a dependent field (picklist or multi-select), configured via a dependency matrix in Object Manager.

Encrypted fields (Shield Platform Encryption)

Concept-level: encrypts data at rest with tenant-specific keys while preserving most standard functionality (search/some formulas restricted). Distinct from the deprecated "Classic Encryption" masked text fields.

Record Types, Page Layouts & Profiles

How the three interact ⭐

User's Profile→Which Record Types they can access→Record Type sets picklist values + business process→Page Layout Assignment (Profile × Record Type)→Layout rendered
  • Record Type controls: which subset of picklist values is available, and which Business Process applies.
  • Page Layout controls which fields/related lists/buttons appear — assigned per Profile + Record Type combination.
  • Business Processes exist only for Opportunity (Sales Process), Case (Support Process), Lead (Lead Process) — not on generic custom objects.
Critical trapField-Level Security (FLS) always overrides Page Layout. If FLS hides a field, it's hidden regardless of layout settings; if FLS makes it read-only, a layout's "required" attribute is irrelevant. Also: a field marked "required" only at the page layout level is UI-only and can be bypassed via API insert — only field-definition-level Required (or a validation rule) truly enforces it everywhere.

External Objects & Salesforce Connect

  • Salesforce Connect maps External Objects to data living outside Salesforce (OData adapter, Cross-Org Adapter, Custom Adapter via Apex Connector Framework).
  • Behaves like a custom object in the UI, but data is not stored in Salesforce — fetched in real time from the external source.
  • Limitations: no triggers, often read-only or limited DML depending on the adapter, no SOSL, no Roll-Up Summary, no Master-Detail involving external objects.
When to useReal-time access to a large external dataset (e.g., legacy ERP) without replicating/syncing it into Salesforce storage. If the data needs heavy Apex/Flow interaction or full feature parity (workflow, approvals, rollups), use a regular custom object with sync/integration instead.

Environments

High-yield

Sandbox types — exact refresh & storage ⭐

TypeRefreshData
Developer1 dayMetadata only, 200 MB
Developer Pro1 dayMetadata only, 1 GB
Partial Copy5 daysMetadata + sample data (~10,000 rows/object), 5 GB
Full29 daysAll data + attachments, matches production storage

Sandboxes always match the production org's Edition. Developer/Developer Pro sandboxes now also support source tracking.

Scratch Orgs

  • Created via Salesforce CLI from a scratch-def.json config file — source-driven, metadata pushed from local source (git as source of truth).
  • Ephemeral: default/max 7 days, extendable up to 30, auto-deleted after.
  • Unlike sandboxes, you choose the Edition in the config file — not tied to production.
  • Ideal for CI/CD, feature-branch isolated dev, disposable/reproducible environments.

Developer Edition org vs Trailhead Playground

  • DE org — free, standalone, own metadata/data from scratch, indefinite lifespan, not tied to any production org. No source tracking — can't be used with DevOps Center.
  • Trailhead Playground — essentially a DE org, sometimes pre-loaded for specific modules, indefinite lifespan, isolated from real work.

Declarative vs Programmatic — the Decision Framework

  • Use declarative when: point-and-click tools (Flow, Validation Rules, Approval Processes, Roll-Up Summary) can meet the requirement — simple field updates/record creation, notifications, straightforward automation, admin-maintainability matters.
  • Use programmatic when: complex business logic beyond Flow's practical limits, complex error handling/rollback, integration with custom auth/retry logic, high-volume bulk processing, or fully custom UI beyond App Builder + Flow Screens.
  • Only declarative possible: page layout assignment, profile/permission set configuration, sharing rules, native Roll-Up Summary fields.
  • Only programmatic possible: complex multi-step transactions with custom rollback, custom auth flows beyond Named Credentials, Batch/Queueable for very large async processing, automated unit-test regression (Apex test classes — no declarative equivalent).
Exam biasWatch for "which is the BEST/MOST efficient solution" (not "which is possible"). Salesforce's guidance always favors the least complex, most maintainable, most declarative option that satisfies the full requirement — the "gray zone" of things both Flow and Apex could do defaults to Flow.

Data Import & Export

Tool comparison ⭐

ToolRow limitObjectsNotes
Data Import Wizard50,000Accounts, Contacts, Leads, Solutions, Custom ObjectsUI wizard, basic dedupe/matching rules
Data LoaderMuch largerVirtually any objectInsert/Update/Upsert/Delete/Hard Delete/Export; relies on External ID + Unique for safe upsert
Bulk APIMillionsAnyAsync, batch — Data Loader switches to it automatically for very large jobs
Mass Transfer Records—Accounts, Leads, Cases, etc.Reassigns ownership in bulk (Setup UI tool)
Mass Delete Records—Standard objectsBulk-deletes matching criteria, moves to Recycle Bin
Weekly Export Service—Whole orgScheduled full CSV/zip export for backup/compliance (Enterprise+ editions)
Trigger phrase"Import Custom Objects / >50,000 records / advanced dedupe" → Data Loader (Wizard caps at 50k and supports fewer objects). "Non-technical admin, one-time small import with built-in dedupe" → Data Import Wizard.

Packages & API Basics

Package types (architecture level)

TypeEditable after install?Upgradeable?Typical use
ManagedNo — code hidden/protectedYes, versionedAppExchange ISV distribution, namespace-protected
UnmanagedYes, fully openNo — reinstall creates duplicatesTemplates, one-time samples, open-source
UnlockedYes, source visibleYes, versionedInternal/first-party source-driven dev (Salesforce CLI, CI/CD)

API family — when to use which ⭐

APISync/AsyncBest for
RESTSyncLightweight web/mobile CRUD integrations
SOAPSyncEnterprise integrations needing a strict typed contract
Bulk API (2.0)Async, batchLoading/exporting large data volumes — migrations, nightly syncs
Streaming APIAsync, event-drivenNear-real-time notifications (PushTopics, CDC, Platform Events)
Metadata APIAsync (long-running)Deploying/retrieving org customizations between environments
Tooling APISyncBuilding dev tools needing fine-grained access to single components
Named Credentials vs Remote Site SettingsRemote Site Settings whitelist an external endpoint URL before any Apex callout can reach it. Named Credentials store endpoint + auth together (superseding Remote Site Settings for auth-carrying cases) so admins can rotate credentials without code changes. A callout to an un-whitelisted endpoint throws System.CalloutException ("Unauthorized endpoint").

Flashcards

Active recall

Answer in your head first, then reveal. Use "Reveal all" in the header to read straight through.