Learning path
Salesforce Developer (Apex & LWC) learning path: everything to study, topic by topic
Certification-grade assessment covering the full Salesforce developer stack: Apex language fundamentals, governor limits and bulkification, trigger frameworks, Lightning Web Components (LWC), REST/SOAP callouts, platform events, and source-driven deployment with SFDX — aligned with the Salesforce Platform Developer I and II exams.
Short answer
To learn Salesforce Developer (Apex & LWC), work through 6 modules and 45 topics in the order they build on each other. It starts with Apex Language Fundamentals, then moves on to Data & Transaction Management and Triggers & Automation Logic. Use the map as a checklist, or measure your level and study only what is missing.
What you will study
Topics are grouped by module. Open one to see its objectives and key concepts.
1 · Apex Language Fundamentals8 topics
Apex Syntax & Primitive Data Types
Core Apex language constructs: primitive types (String, Integer, Long, Decimal, Boolean, Date, DateTime, Id), type casting, null handling, and Apex vs Java differences developers must know for the Platform Developer I exam.
Objectives
- Identify and correctly use Apex primitive types and the Id type
- Handle null values safely to avoid NullPointerException at runtime
- Explain key syntactic differences between Apex and Java
Key concepts
- Apex primitive types
- Id data type
- null handling in Apex
- type casting
- Apex vs Java differences
- String methods
Collections: List, Set & Map
Apex collection types — List (ordered, allows duplicates), Set (unordered, unique), and Map (key-value) — their iteration patterns, common methods, and usage in bulk-safe governor-limit–aware code.
Objectives
- Choose the correct collection type for a given data-management scenario
- Iterate over collections safely in bulk Apex contexts
- Use Map<Id, SObject> patterns to avoid repeated SOQL inside loops
Key concepts
- List<T>
- Set<T>
- Map<K,V>
- iteration with for loop
- collection methods (add/remove/contains/keySet)
- nested collections
SOQL & SOSL in Apex
Embedding SOQL and SOSL queries inline in Apex: SELECT syntax, WHERE/ORDER BY/LIMIT, relationship queries, dynamic SOQL via Database.query(), SOSL multi-object search, and query governor limits.
Objectives
- Write correct inline SOQL with relationship traversal in both directions
- Use dynamic SOQL safely, avoiding SOQL injection via bind variables
- Distinguish when to use SOSL over SOQL for cross-object text search
Key concepts
- inline SOQL
- WHERE / ORDER BY / LIMIT clauses
- parent and child relationship queries
- dynamic SOQL (Database.query)
- SOSL FIND syntax
- query governor limit (100 queries / 50,000 rows)
DML Statements & Database Methods
DML operations (insert/update/upsert/delete/undelete/merge) as statements and via Database class methods; partial-success AllOrNothing flag; DmlException handling; and record-level SaveResult/UpsertResult inspection.
Objectives
- Perform DML using both statements and Database methods, choosing the right approach
- Inspect SaveResult arrays to identify and report partial failures
- Use upsert with External ID fields for idempotent data loads
Key concepts
- insert / update / upsert / delete
- Database.insert(records, allOrNone)
- SaveResult and UpsertResult
- DmlException
- External ID upsert
- merge statement
Control Flow & Exception Handling
Apex control flow constructs: if/else, for/while/do-while loops, break/continue; custom and system exceptions; try/catch/finally; exception properties and best practices for rollback-safe error handling.
Objectives
- Implement loop patterns that remain governor-limit–safe across large data sets
- Create and throw custom exceptions with meaningful messages for LWC error handling
- Structure try/catch/finally blocks to preserve transaction integrity
Key concepts
- if / else if / else
- for loop variants (traditional, list, SOQL cursor)
- try / catch / finally
- custom exception classes
- Exception.getMessage / getStackTraceString
- System.AuraHandledException
sObjects & Schema Introspection
sObject types, generic vs specific sObject, runtime Schema.describeSObjectResult, Schema.DescribeFieldResult, field tokens, and dynamic field access via SObject.get()/put() for flexible, metadata-driven Apex.
Objectives
- Use Schema Describe calls to build metadata-driven Apex logic
- Access and mutate sObject fields dynamically using string-based field names
- Retrieve Record Type info at runtime without hardcoding Record Type IDs
Key concepts
- sObject type hierarchy
- Schema.describeSObjectResult
- Schema.DescribeFieldResult
- SObjectField token
- SObject.get(fieldName) / SObject.put(fieldName, value)
- getRecordTypeInfosByDeveloperName
Apex Classes & Interfaces
Class anatomy in Apex: constructors, static vs instance context, inner classes, virtual/abstract/interface contracts, and common design interfaces such as Comparable, Schedulable, Database.Batchable, and Queueable.
Objectives
- Design Apex class hierarchies using inheritance and interface contracts
- Explain when to use abstract vs interface and how they affect testing
- Implement inner classes as lightweight data-transfer objects
Key concepts
- static vs instance members
- virtual and abstract classes
- interface keyword
- inner classes
- Comparable interface
- class instantiation patterns
Apex Properties & Access Modifiers
Apex access modifiers (private/protected/public/global), property syntax with custom get/set accessors, the with sharing / without sharing / inherited sharing keywords, and the @AuraEnabled annotation for LWC exposure.
Objectives
- Apply the correct access modifier for encapsulation and namespace safety
- Configure with sharing classes to enforce record-level security
- Annotate Apex methods with @AuraEnabled correctly for LWC consumption
Key concepts
- private / protected / public / global
- property get / set accessors
- with sharing / without sharing
- inherited sharing
- @AuraEnabled annotation
- @AuraEnabled(cacheable=true)
2 · Data & Transaction Management8 topics
Governor Limits
Salesforce multi-tenant governor limits enforced per transaction: SOQL query count, DML row and statement counts, heap size, CPU time, callout limits, and how to monitor them with Limits class methods.
Objectives
- List the most critical governor limits and their default thresholds
- Use Limits class methods to proactively check remaining capacity at runtime
- Identify code patterns that will breach governor limits under bulk loads
Key concepts
- 100 SOQL queries per transaction
- 150 DML statements per transaction
- 10,000 DML rows per transaction
- Limits.getQueries() / Limits.getLimitQueries()
- heap size limit
- CPU time limit (10,000 ms sync)
Bulkification Patterns
Design patterns for governor-limit–safe Apex: collecting IDs before SOQL, building Map<Id, SObject> result maps, performing single DML on collections, avoiding SOQL/DML inside loops, and the 200-record trigger batch contract.
Objectives
- Refactor SOQL-inside-loop code to a single bulk query pattern
- Apply Map<Id, SObject> to correlate records without repeated queries
- Design trigger handlers that correctly support 200+ record batches
Key concepts
- SOQL inside loop anti-pattern
- Map<Id, SObject> lookup pattern
- collecting records before DML
- 200-record trigger batch
- Selector layer pattern
- Unit of Work pattern
SOQL Relationship Queries & Aggregates
Parent-to-child (subquery) and child-to-parent (dot notation) relationship queries, aggregate functions (COUNT/SUM/AVG/MIN/MAX/GROUP BY), HAVING clause, and SOQL for loops as a cursor for large result sets.
Objectives
- Write parent-to-child subqueries and traverse results in Apex
- Use aggregate SOQL with GROUP BY to compute summary metrics
- Apply SOQL for loops to process millions of records without heap overflow
Key concepts
- parent-to-child subquery
- child-to-parent dot notation
- aggregate functions (COUNT/SUM/AVG)
- GROUP BY and HAVING
- AggregateResult type
- SOQL for loop (cursor)
Bulk DML Operations & Partial Success
Database.insert/update/upsert with allOrNone=false, iterating SaveResult arrays, error collection and surface strategies, Database.UpsertResult for external-key operations, and the Apex transaction rollback boundary.
Objectives
- Use Database methods with partial-success mode and surface per-record errors
- Design error-reporting patterns that surface failures back to callers
- Explain how partial success interacts with the transaction rollback boundary
Key concepts
- Database.insert(records, false)
- SaveResult.isSuccess() / getErrors()
- Database.UpsertResult
- allOrNone=true vs false
- partial success error collection
- transaction rollback boundary
Transaction Control & Savepoints
Database.setSavepoint() and Database.rollback() for partial transaction reversal, rollback semantics (DML only, not governor limit counts), and patterns for compensating transactions in multi-step workflows.
Objectives
- Implement savepoint-rollback patterns for conditional multi-step DML
- Explain what a rollback does and does not reset within a transaction
- Identify scenarios where savepoints improve data integrity
Key concepts
- Database.setSavepoint()
- Database.rollback(sp)
- Savepoint type
- rollback does not reset limit counters
- compensating transaction pattern
- nested savepoint limitations
Order of Execution
The Salesforce record-save order of execution: system validations, before triggers, duplicate rules, after triggers, assignment rules, workflow rules, processes, flows, escalation rules, and the implications for Apex developers.
Objectives
- Describe the full Salesforce record-save order of execution step by step
- Explain why workflow field updates can re-trigger Apex triggers
- Anticipate interaction effects between triggers, flows, and validation rules
Key concepts
- system validation (required fields, data type)
- before triggers
- after triggers
- workflow field updates re-firing triggers
- process builder and flow in execution order
- duplicate management rules
Asynchronous Apex: Future & Queueable
@future methods for deferred callouts and mixed DML, Queueable interface for chaining and monitoring, System.enqueueJob(), AsyncApexJob tracking, and governor limit changes in async context.
Objectives
- Implement @future methods to perform callouts from trigger context
- Use Queueable to chain asynchronous steps and monitor job status
- Compare @future, Queueable, Batch, and Scheduled Apex use cases
Key concepts
- @future(callout=true)
- Queueable interface
- System.enqueueJob()
- AsyncApexJob object
- chaining Queueable jobs
- higher heap/CPU limits in async
Batch Apex & Scheduled Apex
Database.Batchable interface (start/execute/finish), Database.executeBatch() scope parameter, stateful Batch Apex, Schedulable interface and CRON expressions, and designing Batch jobs that are bulkification-safe and testable.
Objectives
- Implement a Batch Apex job with start/execute/finish for large data processing
- Use Database.Stateful to accumulate state across execute batches
- Schedule Batch Apex via Schedulable and CRON expressions
Key concepts
- Database.Batchable<SObject>
- start / execute / finish methods
- Database.executeBatch(job, scope)
- Database.Stateful interface
- Schedulable interface
- System.schedule() with CRON
3 · Triggers & Automation Logic7 topics
Trigger Context Variables
Apex trigger context variables: Trigger.new, Trigger.old, Trigger.newMap, Trigger.oldMap, Trigger.isInsert/isUpdate/isDelete/isUndelete, Trigger.isBefore/isAfter, Trigger.size, and Trigger.operationType.
Objectives
- Access and navigate trigger context variables for all DML operation types
- Compare field values between Trigger.new and Trigger.old to detect changes
- Use Trigger.newMap for efficient ID-based record lookups within a trigger
Key concepts
- Trigger.new / Trigger.old
- Trigger.newMap / Trigger.oldMap
- Trigger.isInsert / isUpdate / isDelete
- Trigger.isBefore / isAfter
- Trigger.operationType
- Trigger.size
Trigger Design Patterns (Handler Framework)
One trigger per object pattern, trigger handler class separation of concerns, domain-driven dispatch (fflib/Apex Enterprise Patterns), and the TriggerHandler base class pattern for routing context to typed methods.
Objectives
- Implement the one-trigger-per-object pattern with a handler class
- Design a TriggerHandler base class that dispatches to typed context methods
- Explain the maintainability benefits of the handler framework over inline logic
Key concepts
- one trigger per object rule
- TriggerHandler base class
- handler dispatch by context
- fflib ApexTriggerHandler
- separation of trigger routing from business logic
- trigger handler unit testing
Before vs After Triggers
Semantic differences between before and after triggers: when Trigger.new is mutable, when record IDs are available, field updates in before context, and the correct context for querying related records.
Objectives
- Determine whether to use before or after trigger context for a given use case
- Modify record fields in before trigger without an extra DML statement
- Query related records safely in after trigger when IDs are available
Key concepts
- before trigger — record not yet saved
- after trigger — record has ID and is in database
- modifying Trigger.new in before context
- querying inserted record in after context
- before insert / before update / before delete
- after insert / after update / after undelete
Recursion Control
Preventing infinite trigger loops with static Boolean flags, Set<Id>-based deduplication, and context-aware recursion guards; understanding how workflow field updates and process builders can re-invoke triggers.
Objectives
- Implement a static Boolean flag to prevent trigger recursion
- Use a Set<Id> guard for more granular recursion deduplication
- Trace the execution path that causes recursion via workflow field updates
Key concepts
- static Boolean flag pattern
- Set<Id> processed IDs guard
- trigger recursion via workflow field update
- recursion depth limit (16 levels)
- before-update triggered by after-update DML
- context-aware guard reset
Trigger vs Flow Decision Framework
Decision criteria for choosing Apex triggers over record-triggered flows and vice versa: complexity, governor limit implications, testability, maintainability by admins, and Salesforce's 'automate first' guidance aligned with PDI/PDII exam scenarios.
Objectives
- Apply the Salesforce automation decision framework to select the right tool
- Identify cases where Apex triggers are unavoidable over declarative flows
- Explain governor limit considerations that differ between triggers and flows
Key concepts
- record-triggered flow
- Apex trigger complexity threshold
- admin maintainability vs developer flexibility
- governor limits in flows
- Salesforce Well-Architected guidance
- combining flows and triggers
Platform Events in Apex
Publishing and subscribing to Platform Events from Apex: EventBus.publish(), trigger on platform event object, event bus delivery guarantee, ResumeCheckpoint for after-errors-only resume, and decoupled async patterns.
Objectives
- Publish Platform Events from Apex triggers and handlers
- Consume Platform Events in an Apex trigger with ReplayId management
- Explain at-least-once delivery and idempotency requirements for subscribers
Key concepts
- Platform Event definition (API name __e)
- EventBus.publish()
- trigger on MyEvent__e
- ReplayId
- at-least-once delivery
- EventBus.getOperationId()
Apex-Invoked Flows & Flow-Invoked Apex
Calling flows from Apex via Flow.Interview, passing input variables; invoking Apex from flows using @InvocableMethod; InvocableVariable types; bulkification contract for invocable methods and error surface patterns.
Objectives
- Annotate an Apex method with @InvocableMethod for consumption by flows
- Design InvocableVariable inner classes with correct bulk List<> signatures
- Invoke a named flow from Apex using Flow.Interview and inspect outputs
Key concepts
- Flow.Interview.createInterview()
- @InvocableMethod annotation
- @InvocableVariable annotation
- List<Request> / List<Result> pattern
- bulkification in invocable methods
- flow fault path vs exception propagation
4 · Lightning Web Components (LWC)8 topics
LWC Component Structure (HTML/JS/Meta)
Anatomy of a Lightning Web Component: the HTML template file, the JavaScript controller class, the XML metadata configuration, CSS scoping, and the component bundle directory convention.
Objectives
- Create a valid LWC bundle with correct naming conventions and file structure
- Configure the meta.xml file to expose a component on App/Record/Home pages
- Explain how shadow DOM scoping affects CSS in LWC vs Aura components
Key concepts
- component bundle (HTML + JS + CSS + meta.xml)
- template tag and data binding
- JavaScript class extending LightningElement
- meta.xml targets and API version
- shadow DOM and CSS scoping
- SLDS (Salesforce Lightning Design System) classes
Reactive Properties: @track, @api & @wire
LWC reactivity model: @api for parent-exposed public properties, @track for deep object/array reactivity, the default shallow reactivity of class fields, and @wire as a decorator for data binding to wire adapters.
Objectives
- Distinguish @api, @track, and undecorated reactive property behavior
- Expose a public property with @api and validate it in connectedCallback
- Explain when @track is still necessary vs relying on default reactivity
Key concepts
- @api public property
- @track deep reactivity
- default shallow reactivity (LWC Spring 20+)
- @wire decorator
- property vs function wire target
- reactive setter pattern
Wire Service & Apex Methods
Wiring Apex methods and Salesforce wire adapters (getRecord, getPicklistValues, getRelatedListRecords) to LWC components; wire function target for reactive parameter passing; error and data destructuring patterns.
Objectives
- Wire a cacheable Apex method to a component with a reactive parameter
- Handle wire data and error states in the component template
- Use standard Salesforce wire adapters to load record data declaratively
Key concepts
- @wire(apexMethodName, param: $reactiveValue)
- wire result { data, error } destructuring
- getRecord wire adapter
- getPicklistValues wire adapter
- reactive wire parameter with $ prefix
- cacheable=true requirement for wire
Lightning Data Service & Base Components
LightningRecordViewForm, LightningRecordEditForm, LightningInputField, LightningOutputField, and the LDS cache for automatic record operations; lightning-button, lightning-card, lightning-datatable, and other base components.
Objectives
- Build record create/edit/view forms using LDS base components without custom Apex
- Configure lightning-datatable with typed columns and row actions
- Explain how the LDS cache updates propagate across components on the same page
Key concepts
- lightning-record-view-form / lightning-record-edit-form
- lightning-input-field / lightning-output-field
- LDS record cache
- lightning-datatable columns definition
- lightning-card / lightning-button
- SLDS utility classes
Event Handling: Custom Events & Pub/Sub
LWC event model: firing custom events with new CustomEvent(), handling events in parent with template listeners, event bubbling and composed flag, and pub/sub (LMS — Lightning Message Service) for cross-tree communication.
Objectives
- Fire and handle custom events between child and parent LWC components
- Control event propagation using bubbles and composed attributes
- Implement cross-component communication using Lightning Message Service
Key concepts
- new CustomEvent('name', { detail })
- this.dispatchEvent(event)
- on<eventname> handler in parent template
- bubbles and composed flags
- Lightning Message Service (LMS)
- MessageChannel publication and subscription
Navigation & NavigationMixin
Programmatic navigation in LWC using NavigationMixin.Navigate() and NavigationMixin.GenerateUrl(); page reference types (standard__recordPage, standard__namedPage, standard__objectPage, comm__namedPage); and navigation in Experience Cloud contexts.
Objectives
- Navigate to a record, object list, and named page using NavigationMixin
- Generate a URL for a page reference and render it as an anchor link
- Adjust navigation page references for Experience Cloud contexts
Key concepts
- NavigationMixin import
- NavigationMixin.Navigate(pageRef)
- standard__recordPage pageReference
- standard__namedPage (Home, Chatter, etc.)
- standard__objectPage
- Experience Cloud comm__namedPage
Imperative Apex Calls
Calling Apex methods imperatively from LWC JavaScript: promise-based invocation, async/await pattern, error handling with try/catch, and when to prefer imperative calls over @wire (user-initiated actions, non-cacheable mutations).
Objectives
- Call a non-cacheable Apex method imperatively from a button click handler
- Use async/await with try/catch to handle Apex errors in LWC
- Refresh a wired property using refreshApex after an imperative DML call
Key concepts
- import apexMethod from salesforce/apex/ClassName.methodName
- apexMethod({ param }).then().catch()
- async / await with try / catch
- non-cacheable Apex for DML
- refreshApex after mutation
- AuraHandledException message surface
LWC Lifecycle Hooks
LWC component lifecycle: constructor, connectedCallback, renderedCallback, disconnectedCallback, errorCallback; rendering lifecycle guarantees; and best practices for initialization, DOM access, and cleanup.
Objectives
- Explain when each lifecycle hook is called during component mount and unmount
- Access DOM elements safely in renderedCallback with a first-render guard
- Implement errorCallback to catch and surface child component errors
Key concepts
- constructor()
- connectedCallback()
- renderedCallback()
- disconnectedCallback()
- errorCallback(error, stack)
- this.template.querySelector in renderedCallback
5 · Integration & APIs7 topics
REST & SOAP Callouts (HttpRequest/HttpResponse)
Making outbound callouts from Apex: HttpRequest configuration (endpoint, method, headers, body, timeout), HttpResponse status code and body parsing, XML/JSON deserialization, and callout governor limits.
Objectives
- Construct and send an HTTP REST callout with correct headers and body
- Parse a JSON response into an Apex inner class using JSON.deserialize()
- Explain why callouts cannot be made from synchronous trigger context
Key concepts
- HttpRequest / Http / HttpResponse classes
- setEndpoint / setMethod / setHeader / setBody
- JSON.deserialize() / JSON.serialize()
- 10-second callout timeout (default)
- callout from @future or Queueable
- 10 callouts per transaction limit
Named Credentials & Authentication
Named credentials as endpoint + auth containers, Legacy vs Per-User named credentials, credential types (Password, OAuth, AWS Signature), external credential principals, and eliminating hardcoded endpoint URLs from Apex code.
Objectives
- Configure a Named Credential to handle OAuth 2.0 authentication for callouts
- Reference a Named Credential in an HttpRequest endpoint
- Explain the difference between Legacy Named Credentials and External Credentials
Key concepts
- Named Credential (endpoint + auth)
- callout:NamedCredentialName URL prefix
- Legacy vs External Credential
- OAuth 2.0 flow in named credentials
- per-user credential principal
- eliminating hardcoded URLs
Apex REST & Custom Web Services
@RestResource and @HttpGet/@HttpPost/@HttpPut/@HttpPatch/@HttpDelete annotations, RestRequest and RestResponse context objects, URL path parameter binding, and SOAP web services via the webservice keyword.
Objectives
- Implement a custom Apex REST endpoint with URL mapping and HTTP method annotations
- Read request body and URL parameters from RestContext.request
- Return structured JSON responses via RestContext.response
Key concepts
- @RestResource(urlMapping='/api/v1/*')
- @HttpGet / @HttpPost / @HttpPut
- RestContext.request / RestContext.response
- URL parameter binding from urlMapping
- webservice keyword for SOAP
- global class requirement
Platform Events & Change Data Capture
Platform Events for event-driven integration: publishing via Apex and flows, subscribing via CometD and Apex triggers; Change Data Capture (CDC) event objects, ChangeEventHeader fields, and CDC use cases for external system synchronization.
Objectives
- Design an event-driven integration pattern using Platform Events
- Subscribe to Change Data Capture events to sync Salesforce changes externally
- Compare Platform Events and CDC for integration architecture decisions
Key concepts
- Platform Event API name (__e suffix)
- EventBus.publish() from Apex and flows
- CometD long-polling subscription
- Change Data Capture (CDC)
- ChangeEventHeader (changeType, changedFields)
- CDC entity channel subscription
External Services & OpenAPI Import
Registering External Services from an OpenAPI 2.0/3.0 spec, auto-generated invocable actions for flows, named credential binding, schema evolution considerations, and when External Services is preferred over hand-coded callouts.
Objectives
- Register an External Service from an OpenAPI spec in Setup
- Use an auto-generated External Service action in a record-triggered flow
- Explain schema evolution considerations when updating an External Service
Key concepts
- External Services registration from OpenAPI spec
- auto-generated flow invocable actions
- Named Credential binding to External Service
- schema versioning impact
- External Services vs custom Apex callout
- Flow-driven API invocation
Bulk API & Streaming API Overview
Bulk API 2.0 for large-scale data loads/extracts, job lifecycle (upload/close/abort), CSV batch format; Streaming API (PushTopic and Generic Streaming) for real-time notifications; developer awareness for PDII integration scenarios.
Objectives
- Describe the Bulk API 2.0 job lifecycle for large-volume data operations
- Explain when to choose Bulk API over REST API for data integration
- Compare PushTopic Streaming, Platform Events, and CDC for real-time use cases
Key concepts
- Bulk API 2.0 job types (ingest / query)
- job states (Open/UploadComplete/InProgress/JobComplete/Failed)
- PushTopic for Streaming API
- CometD client for Streaming
- Generic Streaming API
- Bulk API vs REST API throughput trade-offs
Integration Security & Remote Site Settings
Remote Site Settings for whitelisting callout endpoints, CSP Trusted Sites for LWC/Aura, OAuth 2.0 flows for inbound Salesforce APIs (Web Server, Username-Password, JWT Bearer), connected apps, and API security best practices.
Objectives
- Configure Remote Site Settings to allow outbound callouts to an endpoint
- Select the correct OAuth 2.0 flow for a server-to-server integration scenario
- Set up a Connected App for external system access with appropriate scopes
Key concepts
- Remote Site Settings (whitelist callout endpoint)
- CSP Trusted Sites for LWC
- OAuth 2.0 Web Server flow
- OAuth 2.0 JWT Bearer flow
- Connected App configuration
- API rate limits and throttling
6 · Testing, Security & Deployment7 topics
Apex Unit Tests & Test Data (@TestSetup)
@isTest class structure, @TestSetup shared data factory, Test.startTest()/stopTest() for governor limit resetting, System.assertEquals/assertNotEquals/assert, and seeAllData=false discipline for test isolation.
Objectives
- Structure an Apex test class with @TestSetup and multiple @isTest methods
- Use Test.startTest() and Test.stopTest() to reset governor limits and flush async
- Enforce test isolation with seeAllData=false and self-contained test data
Key concepts
- @isTest class annotation
- @TestSetup method
- Test.startTest() / Test.stopTest()
- System.assertEquals(expected, actual)
- @isTest(seeAllData=false)
- test data isolation
Code Coverage & Assertions
Salesforce 75% org-wide code coverage requirement for production deployments, 75% per-class trigger coverage, meaningful assertions vs coverage-only tests, and best practices for assertion completeness aligned with PDII exam expectations.
Objectives
- Explain the 75% code coverage requirement and how it is measured
- Write assertions that validate business logic, not just inflate coverage
- Ensure trigger tests cover bulk scenarios with at least 200 records
Key concepts
- 75% org-wide code coverage threshold
- 75% per-trigger coverage
- System.assert / assertEquals / assertNotEquals
- coverage vs meaningful assertions
- covering bulk paths (200 records)
- running tests in developer console vs deploy
Mocking: StubProvider & HttpCalloutMock
HttpCalloutMock interface for testing callouts, Test.setMock() registration, StaticResourceCalloutMock for complex responses; StubProvider interface for dynamic dependency mocking in unit tests without real DML or callouts.
Objectives
- Implement HttpCalloutMock to simulate REST API responses in Apex tests
- Use StubProvider to mock service-layer dependencies without hitting the database
- Register mocks with Test.setMock() and Test.createStub() correctly
Key concepts
- HttpCalloutMock interface
- Test.setMock(HttpCalloutMock.class, mock)
- StaticResourceCalloutMock
- StubProvider interface
- Test.createStub()
- dependency injection in testable Apex
Apex Security: CRUD/FLS, Sharing & Security_ENFORCED
Enforcing record-level sharing with with sharing keyword, checking CRUD and FLS with Schema.describeSObjectResult/DescribeFieldResult, the WITH SECURITY_ENFORCED SOQL clause, and stripInaccessible() for field-level filtering.
Objectives
- Enforce object and field CRUD/FLS checks before DML and SOQL operations
- Apply WITH SECURITY_ENFORCED to SOQL queries as an alternative to manual checks
- Use Security.stripInaccessible() to filter inaccessible fields from query results
Key concepts
- with sharing / without sharing / inherited sharing
- isCreateable() / isUpdateable() / isDeletable()
- isAccessible() for field-level security
- WITH SECURITY_ENFORCED SOQL clause
- Security.stripInaccessible()
- SObjectAccessDecision
SFDX & Source-Driven Development
Salesforce DX (SFDX) CLI: project structure (sfdx-project.json), scratch org creation and features, source push/pull, org shape, and the shift from change-set to source-driven development workflows.
Objectives
- Create a scratch org from a feature definition file using SFDX CLI
- Push and pull source between a scratch org and the project repository
- Explain the advantages of source-driven development over change-set deployment
Key concepts
- sfdx-project.json
- scratch org
- sf org create scratch / sf project deploy start
- source format vs metadata format
- org shape feature definition
- dev hub and scratch org limits
Unlocked Packages & 2GP Managed Packages
Unlocked packages for modular org development: package creation, versioning, install/upgrade; Second-Generation Managed Packages (2GP) for ISVs: namespace, subscriber protections, deprecation, and package dependency management.
Objectives
- Create, version, and install an unlocked package using SFDX CLI
- Explain the subscriber protection model for 2GP managed packages
- Manage package dependencies and version promotion for production release
Key concepts
- sf package create / package version create
- unlocked package install
- package dependency tree
- 2GP namespace locking
- subscriber-protected metadata
- package version promotion
CI/CD & Deployment (Metadata API, Scratch Orgs)
CI/CD pipeline design for Salesforce: SFDX CLI in CI (GitHub Actions / GitLab CI), sf project deploy start with --test-level RunLocalTests, deployment validation (check-only), metadata API retrieve/deploy, and the full path from scratch org to production sandbox to production.
Objectives
- Design a CI/CD pipeline that runs tests and validates before deploying to production
- Use check-only deployment and quick deploy to minimise production downtime
- Explain the differences between MDAPI format and source format deployments
Key concepts
- sf project deploy start --check-only
- --test-level RunLocalTests / RunAllTestsInOrg
- metadata API (MDAPI) retrieve and deploy
- GitHub Actions SFDX pipeline
- sandbox refresh strategy
- deployment validation and quick deploy
Levels: Junior, Mid, Senior, and Expert
Explain it in your own words
Graded by AI · no account · 1 questionNo options to guess from: you write, the AI grades against the topic's rubric and tells you what level your answer reads at.
Already studying Salesforce Developer (Apex & LWC)?
The assessment measures topic by topic, and your plan skips what you already know.
Open to read. An account is only needed to be measured.
Frequently asked questions
Where should I start studying Salesforce Developer (Apex & LWC)?
Start with Apex Language Fundamentals: Apex Syntax & Primitive Data Types, Collections: List, Set & Map, and SOQL & SOSL in Apex. The map orders topics by what they depend on, so each one prepares the next.
How long does a full Salesforce Developer (Apex & LWC) assessment take?
A full assessment of this path takes about 45 minutes. Study time depends on where you start; a diagnostic shows which topics you can skip.
Do I need an account to use this page?
No. The map, objectives and key concepts are open. You only need an account to be measured, get your gap by topic and receive a plan.