Salesforce Platform Developer I Cheat Sheet

Salesforce PDI Tests Apex and Lightning Development Judgment — Not Just Syntax

The exam tests whether you can build secure, scalable Salesforce solutions using Apex, SOQL, and Lightning — and when to use declarative tools instead.

Check Your Readiness →

Among the harder certs

Avg: Approximately 62–67%

Pass: 750 / 1000

Most candidates understand Salesforce Platform Developer I concepts — and still fail. This exam tests how you apply knowledge under pressure.

Core Framework

Salesforce Platform Developer I Framework

PDI tests development on the Salesforce platform. The most critical concept is governor limits — every design decision must account for bulk processing, SOQL query limits, and DML operation limits. One SOQL query in a loop is the most common exam trap.

01
Declarative First — Flow, Validation Rules before writing Apex
02
Apex Fundamentals — Triggers, classes, SOQL/SOSL, DML operations
03
Governor Limits — The most critical Salesforce development constraint
04
Testing — 75% code coverage minimum, meaningful test assertions
05
Lightning Web Components — Component lifecycle, wire service, event handling
06
Security — CRUD/FLS enforcement, sharing rules, with/without sharing

Scenario Traps

Wrong instinct vs correct approach

A trigger needs to update a related record for each Account being processed

✕ Wrong instinct

Query the related record inside the trigger loop for each Account

✓ Correct approach

Collect all Account IDs from Trigger.new, query all related records in one SOQL query outside the loop, store in a Map, then process all records — one SOQL query, not N queries for N records

A developer needs to test an Apex class that makes callouts

✕ Wrong instinct

Make the callout directly in the test and test against the live response

✓ Correct approach

Implement a mock using HttpCalloutMock interface — Salesforce prevents callouts in test context unless a mock is defined

An Apex class should only be accessible by administrators

✕ Wrong instinct

Check the user's profile in Apex and restrict access programmatically

✓ Correct approach

Use Salesforce permissions (Custom Permissions, Permission Sets) to restrict Apex class execution — platform-level security is the correct approach; profile checking in code is fragile

Quick Rules

Know these cold

▸ Never query inside a loop — collect IDs, query once outside, process with a Map
▸ Bulkify all triggers — always iterate Trigger.new, never assume single record processing
▸ with sharing enforces sharing rules; without sharing bypasses them — choose explicitly
▸ Test coverage must include meaningful assertions — not just code execution
▸ CRUD/FLS must be explicitly checked in Apex — it is not automatic
▸ Governor limits — 00 SOQL queries, 150 DML statements per transaction
▸ @future methods for async processing; Batch Apex for large data volumes (>10K records)

Self Check

Can you answer these without checking your notes?

In this scenario: "A trigger needs to update a related record for each Account being processed" — what should you do first?

Collect all Account IDs from Trigger.new, query all related records in one SOQL query outside the loop, store in a Map, then process all records — one SOQL query, not N queries for N records

In this scenario: "A developer needs to test an Apex class that makes callouts" — what should you do first?

Implement a mock using HttpCalloutMock interface — Salesforce prevents callouts in test context unless a mock is defined

In this scenario: "An Apex class should only be accessible by administrators" — what should you do first?

Use Salesforce permissions (Custom Permissions, Permission Sets) to restrict Apex class execution — platform-level security is the correct approach; profile checking in code is fragile

Failure Patterns

Common Exam Mistakes — What candidates get wrong

Writing SOQL queries inside loops

SOQL queries inside loops hit governor limits (100 SOQL queries per transaction). Always collect record IDs in a list, query once outside the loop, and process results in a map. This is the single most tested Salesforce development anti-pattern.

Not bulkifying triggers

Triggers must handle bulk operations — Salesforce processes up to 200 records per trigger invocation. Triggers that assume one record (using Trigger.new[0] only) fail when multiple records are processed.

Ignoring CRUD and FLS enforcement in Apex

CRUD/FLS must be done explicitly using DescribeFieldResult and DescribeSObjectResult. Candidates who assume Apex respects CRUD/FLS automatically fail security enforcement questions.

Writing test methods without meaningful assertions

Salesforce requires 75% code coverage, but coverage without assertions is meaningless. System.assertEquals() must verify expected behavior — not just execute code.

Confusing with sharing and without sharing

with sharing enforces the running user's sharing rules (secure). without sharing bypasses sharing rules (system context). Choosing without sharing when sharing enforcement is required is a security defect.

Salesforce PDI tests development judgment under governor limits. Test whether your Apex knowledge is production-ready.

Start Diagnostic Test → View all exams