Salesforce Platform Developer

The best solution is often not code. You compare formulas, validation, flows and Apex for a given requirement, weigh maintenance and limits, and learn when each choice stops working.

• What formulas and validation rules cover
• What Flow covers
• When Apex is the better answer
• Combining declarative and programmatic parts
• Maintenance cost of each choice
• Writing down the reasoning

You build A decision table that picks a tool for each of a set of requirements.

Code is written against a data model, so you need to read and shape it. You work with objects, fields and relationships, schema tools and record types, and see what the model means for queries and DML.

• Standard and custom objects
• Field types and what they allow
• Lookup and master-detail relationships
• Record types and picklists
• Schema Builder and the object manager
• How the model affects queries and DML

You build A data model for a small app, with relationships chosen for the code that will use it.

Apex is a typed, class-based language that runs on the platform. You write classes, interfaces and methods, use collections and sObjects, and follow the conventions that keep code readable.

• Primitive types, sObjects and collections
• Control flow and loops
• Classes, constructors and access modifiers
• Static members and singletons
• Interfaces and inheritance
• Naming and code style

You build A small Apex service class with an interface and collection logic.

Nearly every Apex class reads or changes data. You write SOQL with filters, relationships and aggregates, use SOSL for text search, and perform DML with attention to bulk behavior and partial success.

• SOQL basics: fields, filters and ordering
• Relationship queries and subqueries
• Aggregate queries and grouping
• SOSL for text search
• Insert, update, upsert and delete
• Database methods and partial success

You build A data access class with queries and DML that run safely on large batches.

Triggers run whenever data changes, whoever changes it. You write triggers for every event, use context variables, handle bulk input, and learn what happens before and after a save.

• Trigger events and context variables
• Before and after triggers
• Handling bulk operations
• A handler class pattern
• Preventing recursion
• The order of execution on save

You build A bulk-safe trigger and handler for one business rule.

Limits are the platform’s rules, and code that ignores them breaks in production. You count queries and DML, move queries out of loops, and use asynchronous Apex when work does not fit in one transaction.

• Per-transaction limits worth memorizing
• Queries and DML outside loops
• Maps and sets to avoid repeated work
• Reading limit usage in code
• Future methods and queueable jobs
• Batch and scheduled Apex

You build A before-and-after refactor that brings a limit-breaking class within limits.

Failures are part of every transaction. You catch and throw exceptions, define custom ones, report errors on records and screens, and use savepoints when part of a transaction must be undone.

• Try, catch and finally
• Common exception types
• Custom exceptions
• Adding errors to records and screens
• Savepoints and rollback
• Handling partial DML failures

You build A service with custom exceptions and a rollback path that is demonstrated by a test.

Lightning Web Components are the standard way to build interfaces. You create components with properties, getters and lifecycle hooks, read data with the wire service, and call Apex from them.

• Component files and structure
• Reactive properties and public properties
• Lifecycle hooks
• Wire service and Lightning Data Service
• Calling Apex from a component
• Events between components

You build A component that shows and edits records, using wire and an Apex method.

Not every screen is a component. You build screen flows that call Apex actions, create Visualforce pages with standard controllers and extensions, and write Apex controllers that serve them.

• Screen flows and invocable Apex
• Visualforce pages and standard controllers
• Controller extensions
• Custom controllers
• Apex methods exposed to components
• Choosing among Flow, Visualforce and components

You build A screen flow that calls Apex, plus a Visualforce page on a controller extension.

Code that reads data must respect who is asking. You enforce object and field access, apply sharing, and guard against injection and cross-site scripting in each interface technology.

• Sharing keywords in Apex
• Enforcing object and field access
• SOQL injection and bind variables
• Cross-site scripting and output encoding
• Cross-site request forgery in Visualforce
• Platform protections for components

You build A security review of a sample class and page, with each flaw fixed.

Untested code is a risk to every other customer’s code on the platform. You write Apex tests for triggers, classes and flows, debug with logs and tools, and monitor asynchronous jobs once they run.

• Test classes and test methods
• Test data and isolation
• Assertions that prove behavior
• Testing triggers, classes and flows
• Debug logs and the Developer Console
• Monitoring asynchronous jobs
• Coverage and what it does not prove

You build A test suite for a trigger, a class and a flow, with a debugged failure.

Code that stays in one org is not shipped. You work in a scratch org, keep source in version control, and deploy with the Salesforce CLI, with tests run along the way.

• Project structure and source format
• Creating and using a scratch org
• Pushing and pulling source
• Deploying and validating with the CLI
• Running tests during deployment
• Moving through sandboxes to production

You build A project deployed from a scratch org to a sandbox with validated tests.

Build one small app from end to end: the data model, automation, Apex, an interface and tests. You choose declarative or coded parts on purpose, secure it and deploy it from source.

• Scoping a small business app
• Building the model and the automation
• Writing code and the interface
• Securing, testing and deploying
• Reviewing what you would change

You build A working custom app with data model, Apex, a component, tests and a deployment.