Salesforce Developer Journey: A Five-Stage Roadmap
🎯 Build on a platform you understand
Section titled “🎯 Build on a platform you understand”This journey is a Salesforce developer roadmap for people beginning Salesforce development, admins moving into code, and developers bringing experience from another stack. By completing the practice work, you’ll be able to build, query, integrate, test, and deploy a Salesforce solution in a learning environment, and explain when configuration, Flow, or code is the right layer for the job.
I know this firsthand. My own Salesforce journey started as a Technical Test Analyst. I had never even heard of Salesforce until it became part of the architecture I was testing. That exposure sparked my interest, and I eventually transitioned into a Salesforce Developer role.
Early on, I was confident in my abilities because I could write Visualforce and Apex and I was building solutions that worked, passed testing, and looked correct on the surface. But that confidence didn’t last long.
I remember building an Apex solution that worked perfectly in a controlled environment, but started failing when exposed to real data volumes because it hit governor limits. In another case, I built functionality that behaved correctly for me as an admin user but didn’t work properly for real users. I hadn’t fully accounted for field-level security and the sharing model, which meant users couldn’t see the data as intended.
Fixing those issues forced me to step back and realise I was missing critical understanding of how the platform actually works.
Learning about limits, data models, roles, permissions, and sharing fundamentally changed how I approached development. My solutions became more reliable, more scalable, and far easier to maintain. That experience is exactly why I strongly advocate for developers to learn the fundamentals first, and why this guide is structured the way it is.
Stages 1 and 2 give those lessons a place in your learning: understand the platform and effective access first, then learn how the org is configured, observed, tested, and changed. That context will shape the code you write in Stage 3 and the interfaces you build in Stage 4. Stage 5 brings that work together in one change you can test, release, recover, and hand over.
If you’d rather start now, Stage 1 begins with What is Salesforce?; the rest of this page is the map you’ll come back to at the end of each section.
🚧 What this journey prepares you for
Section titled “🚧 What this journey prepares you for”This is a practical learning path, not a certification course. It helps you build work you can explain and submit for review; completing it doesn’t grant authority to change a production org. Production responsibilities, approvals, and release access belong to the team that owns that org.
Work in a practice org or an authorised sandbox throughout. When a chapter discusses production deployment or incident response, rehearse the decisions and checks in your learning environment and record that scope in your evidence.
👤 Understand the developer role
Section titled “👤 Understand the developer role”If you’re deciding whether this work suits you, read Exploring the Role of a Salesforce Developer. It explains the responsibilities and boundaries you’ll encounter. This is optional role orientation, not a stage in the journey.
🧭 How to use the map
Section titled “🧭 How to use the map”The Guides menu groups chapters into sections, such as Salesforce Fundamentals. A stage is one of those sections read as part of this journey: you start at its first chapter and read in menu order until you reach the end of the stage. Usually that is the section’s last chapter; in Stage 2 it is a named stop point partway through the menu.
| Map term | What it means here |
|---|---|
| Core | The required chapter range and practice evidence for a stage. Evidence means the work you keep to show you can do it: records, decisions, test results, and recovery notes, listed under each stage below. |
| Named stop point | The chapter after which you leave a section even though its menu continues. Stage 2 stops after Sandbox Strategy & Change Management. |
| Optional deep dive | A separate guide for greater depth, listed after the relevant core stage. It doesn’t extend that stage’s required range. |
| Transition | The link from a completed stage to the first chapter of the next included section. |
The route is fixed: five stages, in order, with nothing to choose between. Two things sit alongside it rather than on it: the optional artificial intelligence (AI) extension, and the deep-dive guides listed.
📍 How your experience changes the pace
Section titled “📍 How your experience changes the pace”The route is the same for everyone and begins at Stage 1, even if your first step there is checking its evidence against work you have already done. What experience changes is how quickly you can show a stage’s evidence and move on, not where you start.
| Starting profile | How to approach the journey |
|---|---|
| Beginner | Read and practise in order. Use the stage evidence as a checklist of what to keep, and return to the teaching chapter when a check fails. |
| Admin moving to code | Stages 1 and 2 are mostly evidence checks against work you can already demonstrate safely: confirm you can explain effective access, test a Flow failure, and rehearse a recovery. Expect to spend most of your time in Stages 3 and 4, where Apex, testing, and the user interface (UI) frameworks are new. |
| Developer from another stack | Stages 1 and 2 are where your time goes: the platform constraints, the sharing model, and what Flow already does are what change how you write code here. Stages 3 and 4 move faster because the syntax is familiar, though governor limits and multitenant behaviour still take real time. Even so, build the Expense Claim pieces listed below the table, because Stage 5 starts from them. |
Skipping requires evidence, not a job title or familiarity with the vocabulary. If you can demonstrate a stage’s outcomes and explain its failure/recovery check, use that evidence to complete the stage review and continue. Otherwise, work through its required range. Evidence from your own projects can’t replace the Expense Claim work Stage 5 needs, though: the object you create in Developer Mindset & Toolkit, the payment build in Asynchronous Apex, the returned-payment integration in Integrations, and the reimbursement triage component in Lightning Web Components. Build those four in your practice org whichever pace you take. Practice safety, effective-access testing, change testing, and rollback thinking are never waived.
🔐 Keep practice safe and repeatable
Section titled “🔐 Keep practice safe and repeatable”Salesforce Practice Orgs & Safe Learning, the third chapter of Stage 1, explains how to prepare your environment and recover from an experiment. You’ll reach it on the route, so there’s no need to read it now; the rules below apply from the first chapter. Use synthetic records, keep real customer data out, and make no production changes for this journey. Check the target org before running a command, importing data, or activating a change; keep email and integrations isolated from real recipients and systems.
Build the habit of checking with a representative user’s access. Use Log In As where your org permits it, or ask the tester to use their own session. Record the user’s permissions and the expected result as well as what happened. An admin-only success doesn’t complete an access check.
Keep a small evidence folder alongside your project: the org context, design decisions, source or configuration versions, test results, and recovery notes. Mark unrun checks as Not run, and distinguish a sandbox rehearsal from a production release.
📋 The roadmap: five sections in order
Section titled “📋 The roadmap: five sections in order”The required route is five sections in this order. The Administration stop point keeps the journey focused on the configuration and operational knowledge your development work depends on.
Stage 3 introduces Salesforce Object Query Language (SOQL) and Salesforce Object Search Language (SOSL), the query and search languages you’ll use to retrieve Salesforce records.
| Stage | Section | Required range | Outcome |
|---|---|---|---|
| 1 | Salesforce Fundamentals | Whole section | Understand the platform, licences, safe environments, users, data model, declarative configuration, reporting, data management, and effective record access before writing code. |
| 2 | Salesforce Administration | Start through Sandbox Strategy & Change Management | Understand how a real org is observed and changed, what the standard UI and Flow already provide, how deployable configuration works, and how changes are tested, released, and recovered. |
| 3 | Salesforce Development Fundamentals | Whole section | Build with Apex, SOQL/SOSL, triggers, limits, asynchronous processing, integrations, tests, and deployment discipline. |
| 4 | Salesforce Development UI Fundamentals | Whole section | Understand and build across Visualforce, Aura, and Lightning Web Components, including coexistence and migration. |
| 5 | Salesforce Developer Practice | Whole section | Deliver a change to the Expense Claim system with representative-user and bulk tests, a release and rollback rehearsal, and an evidence pack for handover. |
🪜 Work through the five stages
Section titled “🪜 Work through the five stages”Each stage lists its core chapters, the evidence to keep, one failure you should be able to recover from before moving on, any optional deep dives, and where to go next. Use the evidence and the recovery check to decide when you are ready to continue, and keep both with the work from each section.
🧱 Stage 1: Salesforce Fundamentals
Section titled “🧱 Stage 1: Salesforce Fundamentals”When you finish this stage, you should be able to read an org, explain its data model and access, make a first configuration, and answer a business question from its records. It comes first because you need to understand the environment your solution will run in before deciding how to build it. This is the foundation I was missing when my early code failed for real users and data volumes.
Core, in menu order:
- What is Salesforce?
- How the Salesforce Platform Works
- Practice Orgs & Safe Learning
- Users
- Data Model
- Customisation & Automation
- Reports & Dashboards
- Data Management
- Record Access
Keep as evidence:
- Your Read Your Org record.
- The Equipment Request configuration and data-model decisions.
- A report and dashboard with a defined question and audience.
- The access-change rationale and the Record Access checkpoint: predicted access, positive and negative checks, and the result of removing a grant deliberately.
- Your practice change log and data import and recovery notes.
Recovery check: a record you can see as the admin is invisible to the user who needs it. Reproduce it with that user’s access, trace the permission and sharing layers, and correct the smallest relevant grant. Repeat both the allowed and denied checks before accepting the fix.
Optional deep dive: Salesforce Security and Access develops the sharing and troubleshooting work further, picking up where the Record Access checks stop. It is outside the core range.
Next included section: Salesforce Administration, beginning with Org Health & Monitoring.
🔧 Stage 2: Salesforce Administration
Section titled “🔧 Stage 2: Salesforce Administration”You should leave this stage able to observe an org, shape its standard UI, build and test Flow automation, and prepare a controlled, recoverable change. Stage 1 established what the platform and its access model do; this stage shows how those controls interact in an org somebody has to operate. Learning that first gives you a reasoned basis for choosing Flow or Apex later.
Core, in menu order:
- Org Health & Monitoring
- Advanced UI Customisation
- Automation
- Custom Metadata Types & Custom Settings
- Testing Configuration Changes
- Sandbox Strategy & Change Management — the named stop point for this journey.
The later Administration chapters belong to the Admin route. After the stop point, use the transition below to enter Development Fundamentals.
Keep as evidence:
- A monitoring cadence and incident record using the triage example: symptom, scope, recent change, containment, owner, and follow-up.
- The Support Workspace checkpoint: the focused app, activated Case record page, assignment record, and completed checks as a support agent and team lead.
- The required Case follow-up Flow build: a before-save flow that stamps the follow-up date, an after-save flow that creates the task, its fault path, and the positive, negative, and forced-failure results described in What you should have.
- A reasoned Custom Metadata versus Custom Settings decision, the representative-user and regression results from Testing Configuration Changes, and a release runbook covering dependencies, validation, communication, rollback, and monitoring. Label your deployment and recovery work as sandbox rehearsals.
Recovery check: a case closes but the follow-up task is missing. Use the incident-record method to identify the failed work and relevant change. Rehearse restoring the previous working version, verify a fresh case, and account separately for missing tasks. A successful save alone doesn’t prove the automation completed.
Next included section: Salesforce Development Fundamentals, beginning with Developer Mindset & Toolkit.
🧰 Stage 3: Salesforce Development Fundamentals
Section titled “🧰 Stage 3: Salesforce Development Fundamentals”When you leave this stage you should be able to implement Apex with deliberate transaction boundaries, retrieve data safely, integrate with another system, and test and deploy the result in your practice environment. The previous stage gave you configuration and Flow to compare against; now you can explain why a requirement needs code and how that code will be operated.
Core, in menu order:
- Developer Mindset & Toolkit
- Apex Basics
- Querying Data with SOQL & SOSL
- Triggers, Limits & Bulk Patterns
- Asynchronous Apex
- Integrations
- Testing & Deployment
Keep as evidence:
- The working Prepare a Query for Bulk Trigger Logic capstone, with representative-access results. Add relationship queries and a SOSL example from the same chapter, explaining filtering, data volume, and query-plan reasoning where relevant.
- The Expense Claim payment build, with its trigger, Queueable, nightly retry, test results, and the platform constraints behind those choices.
- The connected returned-payment integration, with authentication ownership, the two contracts, mocked success and failure results, and the live authenticated check or its Not run record.
- Source history, meaningful positive and negative tests, and a deployment rehearsal with validation results and the monitoring and rollback record carried forward from Stage 2.
The query exercise is a named capstone. The Expense Claim builds connect asynchronous processing and integrations, and Stage 5 changes that same system. Keep the working source and setup in your project; reading the code blocks isn’t the same as having run and tested them.
Recovery check: code works for one record but fails for a batch. Reproduce the batch failure in the practice org, inspect the queries and writes, and apply the collect/query/process pattern taught in Triggers, Limits & Bulk Patterns. Keep the failing test and its passing retest rather than shrinking the test data until the error disappears.
Optional deep dives: the SOQL Guide, SOQL Advanced Guide, and SOSL Guide extend querying after the core stage.
Next included section: Salesforce Development UI Fundamentals, beginning with Evolution of Frameworks.
🧩 Stage 4: Salesforce Development UI Fundamentals
Section titled “🧩 Stage 4: Salesforce Development UI Fundamentals”You should leave this stage able to build and assess Salesforce interfaces across Visualforce, Aura, and Lightning Web Components (LWC), and explain how they can coexist or be migrated. This follows Development Fundamentals because a user interface needs the same access, data, error-handling, and testing decisions as the code beneath it. The history matters when you inherit an existing page as well as when you build a new component.
Core, in menu order:
- Evolution of Frameworks
- Visualforce
- Aura
- Lightning Web Components
- Coexistence, Migration & Best Practices — the required end of this section.
Keep as evidence:
- The Visualforce Searchable Contact List with Pagination capstone, with its observed behaviour and tests.
- The Aura Greeting Card with Child Component and Event capstone, with its observed behaviour and tests.
- The LWC Account Contact Explorer capstone, with its observed behaviour, tests, and deployed record-page checks.
- The LWC reimbursement triage build, with its Jest results and both support-user checks, including the error the page showed when a filter field was hidden.
- The LWC readiness checklist results covering accessibility, representative-user security, and loading, empty, error, and success states.
- A short coexistence or migration decision using the final chapter’s leave / maintain / extend / migrate framework.
Recovery check: the page looks finished but gives no useful feedback when its data request fails. Reproduce the failure, add and test the missing state, then check the page as a representative user and with the keyboard. Re-run the successful path too, so the error handling doesn’t break the normal interaction.
Next included section: Salesforce Developer Practice, beginning with the Expense Claim capstone.
📦 Stage 5: Salesforce Developer Practice
Section titled “📦 Stage 5: Salesforce Developer Practice”When you finish this stage, you should be able to deliver one change to a working system, from the agreed contract through Apex, access, UI, tests, release, and handover, with evidence a reviewer can assess. It comes last because the change is to the system you’ve already built: the payment build, returned-payment integration, and triage component from Stages 3 and 4. Finance can now reissue a returned payment, and support needs a safe way to request it.
Core, in menu order:
Keep as evidence:
- Finance’s change notice, your acceptance criteria and decision log, and the state and permission contract.
- The working source, setup metadata, regression baseline, and recorded application programming interface (API) versions.
- Positive, negative, bulk, and representative-user test results, per-class coverage, and the manual support-user checks. Mark checks you haven’t run as Not run.
- The release and rollback rehearsals, your checks of switching reissues on and off with a permission set, and the recovery record.
- The handover, known limits with owners and next actions, and a short retrospective.
Recovery check: remove a field grant the payment job needs, observe the failed job as well as the accepted request, restore access, and record the retry path. Rehearse the rollback while no payment has been made under a reissue’s new payment key. After that, the old code can’t recognise those payments’ returns, so switch reissues off, reconcile every reissue still in progress with finance, and fix the fault in the new code instead of rolling back.
Next: take the reviewed evidence pack to the completion review below. Further capstone extensions and AI are optional after this required stage.
✅ See how far you have come
Section titled “✅ See how far you have come”When you reach the end of Stage 5 and want to see how far you’ve come, this is the place to look. Go back over the evidence you kept and use the table below as a guide. Each row is a capability rather than a chapter, so it shows what your work adds up to, and it’s a useful shape if you ever need to walk someone else through it. For each row, note the artefact, where you did it, what you observed, and anything still open, and mark anything you haven’t run as Not run.
The querying and UI chapters have named capstones. The connected Expense Claim builds and Stage 5’s change supply the asynchronous, integration, testing, and integrated-delivery evidence. A capability is complete when its checks have passed and you can explain the result.
| Capability | What shows it, and where it comes from |
|---|---|
| Platform and implementation judgement | An org-context record, an explanation of effective access, and a reasoned configure-versus-Flow-versus-Apex decision. From Platform, Record Access, Automation, and Triggers, Limits & Bulk Patterns. |
| Apex and transaction design | Working Apex with clear responsibilities, bulk-safe behaviour, limit awareness, and a failure or escalation path. From Apex Basics and Triggers, Limits & Bulk Patterns. |
| Querying and data access | The Prepare a Query for Bulk Trigger Logic capstone, plus SOQL and SOSL examples that show relationships, filtering, access enforcement, and data volume. From Querying Data with SOQL & SOSL. |
| Event and asynchronous processing | The Expense Claim trigger, payment Queueable, and nightly retry, with their test and monitoring results. From Asynchronous Apex, extended by Stage 5’s capstone. |
| Integration | The payment and returned-payment contracts, credential setup, and mocked results from Integrations, plus the attempt-key and replay checks in Stage 5. |
| Testing and delivery | Stage 5’s positive, negative, bulk, and representative-user tests, coverage, and release and rollback rehearsals. It applies Testing & Deployment and the change discipline from Stage 2 to the connected system. |
| User interface | The Searchable Contact List with Pagination, Greeting Card with Child Component and Event, and Account Contact Explorer capstones and the reimbursement triage build, with their accessibility, security, and error-handling checks, and a coexistence or migration decision. From the Visualforce, Aura, LWC, and Coexistence chapters. Stage 5 adds the reissue quick action, its Jest results, and a regression run of the triage tests. |
| Integrated delivery | The Expense Claim capstone: one connected change with an evidence pack, known limitations, handover notes, and a short retrospective on its design choices. |
A gap shows you what to practise next. Note the capabilities you can show and return to any checks still open, especially where the capstone depends on an earlier build. And if someone is reviewing your work with you, this table is a good thing to bring.
🎓 After the journey
Section titled “🎓 After the journey”When you’re ready, choose a direction that fits the work you want to do:
- AI & the Salesforce Developer is an optional extension for considering AI in your development work. It sits outside the five core stages.
- Understanding the Role of a Salesforce Architect helps you explore broader design and governance responsibilities.
- The Salesforce Admin Journey takes the other direction, deepening configuration and administration. Fundamentals and the opening Administration chapters are shared; use your evidence when reviewing those stages.
- The SOQL, SOQL Advanced, and SOSL guides deepen querying, while Salesforce Security and Access develops sharing and access troubleshooting.
🔄 Keep your learning current
Section titled “🔄 Keep your learning current”When an org upgrade, API version change, or unexpected result affects your work, check the Salesforce release notes pinned to the release your org is on (the page defaults to the newest published notes, which can be a release no production org runs yet), the Apex Developer Guide, Lightning Web Components Developer Guide, and Apex governor-limits reference. Match the guidance to your org and code versions, then repeat the affected checks and update your evidence.
🚀 Next steps: start Stage 1
Section titled “🚀 Next steps: start Stage 1”Stage 1 is Salesforce Fundamentals, read in menu order from its first chapter to Record Access. When you reach the end of the section, come back to this map to check your evidence and follow the transition to Salesforce Administration.