Salesforce Admin Journey: A Five-Stage Roadmap
🎯 Why this journey exists
Section titled “🎯 Why this journey exists”Plenty of people become Salesforce Admins without ever applying for the job. The org needs a new field, then a report, then a user unlocked, and gradually you’re the person everyone asks. Others start deliberately: a new role, a career change, or a team that finally needs dedicated admin capacity. Either way, the challenge is the same. Salesforce is easy to change and harder to change well, and the gap between the two is where orgs accumulate confusing fields, brittle automation, and permissions nobody can explain.
This roadmap is a structured route through that gap. It takes you from understanding what the platform actually is, through building a first application someone could use, to the operational habits that keep a real org healthy, then into a standard Salesforce product, and finally to delivering a change to something people already depend on. It ends with you taking one request from a brief to a tested, released, and handed-over change, keeping the evidence at every step.
You don’t need any Salesforce experience to start. If you already have some, the starting profiles below will help you find where your time best goes.
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 learning path, not a certification course. Some of it is reading, and some of it has you build work you can explain and submit for review. What you may change in a real org is set by that org’s governance: its change process, who approves, and who holds release access. The journey prepares you to work within those controls.
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.
This journey covers the ground an admin uses most, not everything the role can grow into. Administering a particular product in depth, and the judgement that only comes from running an org through a few release cycles, sit beyond it. Finishing it means you can do the core of the job and show the evidence. The depth comes from real orgs: I’ve worked with Salesforce for over ten years and I’m still learning.
👤 What a Salesforce administrator does
Section titled “👤 What a Salesforce administrator does”If you’re deciding whether this work suits you, read Understanding the Role of a Salesforce Administrator. It explains what admins own day to day, the skills that matter, and how the role fits alongside developers and architects. If you’re still weighing up which role fits you at all, Salesforce Roles: Admin, Developer, or Architect? compares the three side by side. Both are optional 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 to the section’s last chapter. Inside a section the previous and next links carry you, so you only need this page at the boundaries.
| 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. |
| Choose one section | A stage where the route is one whole product section rather than a fixed one. Stage 4 is this kind of stage; the section on the route today is Service Cloud Administration. |
| 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 first stage and the opening chapters of the third are shared with the Salesforce Developer Journey, and that’s intentional. Admins and developers work on the same platform, with the same data model and the same security rules. Developers leave Salesforce Administration after Sandbox Strategy & Change Management; you read the whole section, because the chapters after that point are the ones an admin owns.
Chapters link to Trailhead throughout, because it’s an excellent learning source in its own right: it explains the same ground from Salesforce’s side, which compounds what the chapter taught and can add context the chapter didn’t have room for, and it’s where more hands-on work lives. Those links can add the practice half of each chapter: a module gives you a challenge in your practice org, a project builds the same thing on different data, and a superbadge checks the skill against a scenario you haven’t seen. The capstone at the end of the journey lists the superbadges that map onto its completion criteria.
📍 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. What experience changes is how much of it you need to do: a beginner should work through every chapter, while someone who already runs an org can move quickly through the early stages and spend their time where the material is new.
| 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. |
| Power user or adjacent role | You already use Salesforce every day, so the first two chapters of Stage 1 will be quick reading. Slow down for Users, Data Model, and Record Access anyway: those three chapters tell you which layer an access problem belongs to. Expect Stages 2 and 3 to be where most of the new material is. |
| Working admin filling gaps | Stages 1 and 2 are mostly checks against work you can already demonstrate safely: confirm you can explain effective access, test a change as a representative user, and rehearse a recovery. Your time goes into the Stage 3 chapters that cover work your org has not asked you to practise in depth, and into Stages 4 and 5, which ask you to prove it on a product and on a change. The Stage 2 build and the Stage 3 Case build are the exception to checking; both are needed later, so build them even where the rest of the stage is a check. |
Use the stage outcomes and recovery check to decide how quickly to move. If you can demonstrate both, record that in the stage review and continue; otherwise, work through the required range. Later stages depend on two builds: Stage 5 changes the Equipment Request app from Stage 2, and Stage 4 starts from the Support Workspace, follow-up flow, and Resolution Notes built in Stage 3. Keep those builds, along with the practice-safety, effective-access, change-test, and rollback evidence, whichever pace you take.
🔐 Keep practice safe and repeatable
Section titled “🔐 Keep practice safe and repeatable”Practice Orgs & Safe Learning, the third chapter of Stage 1, explains how to prepare your environment and undo something that went wrong. 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 importing data or activating a change, and 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. Until a representative user has passed it, the check is still open.
Keep a small evidence folder alongside your work: the org context, design decisions, configuration versions, test results, and recovery notes. Mark unrun checks as Not run, and distinguish a sandbox rehearsal from a production release. By Stage 5 that folder becomes the evidence pack a reviewer reads.
📋 The roadmap: five sections, two builds
Section titled “📋 The roadmap: five sections, two builds”The required route is five sections in this order. Each is read whole, in menu order.
| Stage | Section | Outcome |
|---|---|---|
| 1 | Salesforce Fundamentals | Understand the platform, practise safely, manage basic users and access, model and manage data, make a first configuration, and answer a business question. |
| 2 | Salesforce Admin Essentials | Turn a request into a maintainable, secure, reportable first application with an org baseline and recoverable business rules. |
| 3 | Salesforce Administration | Read an org, shape the user experience, automate safely, manage configuration, test and release changes, implement a justified approval, operate email, and support adoption. |
| 4 | Service Cloud Administration (choose one section) | Configure and test one standard Salesforce product process rather than treating administration as custom-object work only. |
| 5 | Salesforce Admin Practice | Deliver a change to the Equipment Request app the way you would on a live org, and review the evidence pack against the completion criteria. |
Two builds run the length of the journey, and knowing which one you’re on tells you why a chapter is where it is.
- Equipment Request is the custom-platform build: an app you design from a brief, where staff request equipment, managers approve, IT fulfils, and Finance sees the spend. Stage 1 makes a first version of it in Customisation & Automation. Stage 2 builds it properly, from requirements to imported backlog. Stage 5 changes it after it has been live for a quarter. You finish with an app whose routing rules are data, a release record, and an evidence pack that lets another admin maintain it.
- The Case support process is the standard-product build: a support workspace, a follow-up flow, resolution notes, queues, assignment, escalation, and email intake, all on the Case object Salesforce already provides. Stage 3 builds the workspace and the follow-up automation, then tests and releases a change to it. Stage 4 configures the support process itself in Service Cloud. You finish with a working support process, persona access checks, an email exchange, and a reconciled backlog report.
Both builds are here because they prove different things. Building a custom app from a brief shows you can design, secure, and change something that didn’t exist before. Configuring a product people already bought shows you can work inside a standard object model, its built-in automation, and its reporting without inventing what Salesforce already provides. Being strong on one doesn’t cover for the other.
🪜 Work through the five stages
Section titled “🪜 Work through the five stages”Each stage lists its core chapters, any build it advances, the evidence to keep, and the next section. Use the evidence and the recovery check to decide when you’re ready to continue, and keep both with the work from each section.
🧱 Stage 1: Salesforce Fundamentals
Section titled “🧱 Stage 1: Salesforce Fundamentals”This stage teaches you what the platform is made of: the data model, how access is decided, what a first configuration involves, and how a business question is answered from the records. It comes first because this is where the vocabulary comes from. Objects, fields, relationships, profiles, permission sets, record IDs: every later chapter assumes you hold these already, and much of what confuses admins further on traces back to one of them being only half-understood. Read it in order, because the sequence carries the dependencies: Users before Record Access, since sharing only makes sense once you know what a profile and a permission set already grant, and the data model before customisation, reports, and data management, since all three are built out of objects and fields.
Build: Equipment Request, first version. Customisation & Automation has you create the object and a first flow, so you meet the app before Stage 2 asks you to design it properly.
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: edition, licences, environment type, and where its controls live.
- The persona-to-permission matrix and onboarding checklist from Users, and the first Equipment Request object and flow with the decisions behind them.
- A report and dashboard with a defined question and audience.
- The Record Access checkpoint: predicted access, positive and negative checks, and the result of removing a grant deliberately.
- Your practice change log and the data-quality plan and recovery rehearsal from Data Management.
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, run the three checks from Record Access in order, and correct the smallest relevant grant. Repeat both the allowed and denied checks before accepting the fix.
From experience: when someone can’t see the records they need, the instinct is to grant a permission, and I’ve seen View All Records handed out on an object when the real fix was a sharing rule that needed correcting. Correcting the smallest relevant grant is the habit that prevents it.
Optional deep dive: Record Access carries the model you need, including the checks that settle most access complaints. Salesforce Security and Access is for the day an investigation runs past them, or a requirement runs past organisation-wide defaults, the hierarchy, and sharing rules. Start with Advanced Sharing & Scale, then use Access Troubleshooting on a real complaint. It’s outside the core range.
Next included section: Salesforce Admin Essentials, beginning with Requirements & Solution Design.
📝 Stage 2: Salesforce Admin Essentials
Section titled “📝 Stage 2: Salesforce Admin Essentials”The fundamentals teach you what the platform can do. This stage teaches you to decide what it should do, and then to build it. One request runs the length of the section: you gather it, write it down as acceptance criteria, settle the org baseline it will live in, turn the criteria into rules, build the app, test it as four other people, and finally load the backlog that existed before it. Configuration is fast, which is exactly why the deciding comes first. Read it in menu order: Org Setup before any building, since locale, currency, and fiscal year change what your fields and formulas mean; Declarative Business Rules before the build, since the build implements its decision record; and the three chapters grouped under Build the App as one continuous build rather than three separate exercises.
Build: Equipment Request, done properly. You leave with the object, its access model, a Flow approval process, two reports, and the imported history, all tested as someone other than you.
Core, in menu order:
- Requirements & Solution Design
- Org Setup: Company Settings & Login
- Declarative Business Rules
- Object, Fields & Access (Build the App)
- Flow Approval Process (Build the App)
- Test Permissions & Reports (Build the App)
- Data Import & Reconciliation
Keep as evidence:
- The one-page Equipment Request brief with its acceptance criteria and what you ruled out of scope.
- The org baseline record from Org Setup, including the two settings you can’t undo, and the business-rules decision record with each rule’s layer.
- The built app: object, fields, validation rules, permission sets, sharing rules, record page, the manager review flow, and the approval process.
- The acceptance results as four personas, with the two reports and who could see what.
- The import: source, mapping, success and error files, and the reconciliation that accounts for every row and the total they add up to.
Recovery check: Data Import & Reconciliation loads the app’s historical requests from a file, a small pilot batch first and then the rest, and each record carries the legacy ID it had in the old system. It then rehearses a correction: a second, smaller file that changes one field on an existing record by matching on that legacy ID, which Salesforce calls an upsert.
The failure to recover from is that correction changing a cost that should have been left alone. Confirm the upsert matched the record you meant (same Salesforce ID, no new record created), put the original value back with an Update keyed on that Salesforce ID rather than by re-running the load, and show the field history carrying both the change and the restore. Also account for every row the pilot batch rejected and what you changed before retrying.
Next included section: Salesforce Administration, beginning with Org Health & Monitoring.
🔧 Stage 3: Salesforce Administration
Section titled “🔧 Stage 3: Salesforce Administration”This stage focuses on how to run an org: the operational skills that separate someone who can configure an org from someone an organisation can rely on. A lot of what goes wrong in a mature org is a change that was made without a way to test it, monitor it, or roll it back. It starts with Org Health & Monitoring because that chapter teaches reading an org before changing one. The middle of the section is one argument in three parts (Custom Metadata, Testing Configuration Changes, and Sandbox Strategy), each about a change surviving contact with production.
Approval Process, Email Templates, and Adoption come after the point where the Developer Journey leaves the section, because they’re the chapters an admin likely owns outright. The section closes on adoption because a change is only finished once people use it.
This stage also changes how you learn. Stage 1 can be absorbed from the page, but monitoring, deliverability, and change management are about evidence from a running system, and reading alone won’t get you there.
Build: the Case support process begins here. Advanced UI Customisation builds the Support Workspace, Automation adds the follow-up flow when a case closes, Testing Configuration Changes and Sandbox Strategy test and release the Resolution Notes change to it, and Org Health’s incident walkthrough triages that same flow. Email Templates and Custom Metadata borrow the Equipment Request approval for their examples, so both builds stay in view.
Core, in menu order:
- Org Health & Monitoring
- Advanced UI Customisation
- Automation
- Custom Metadata Types & Custom Settings
- Testing Configuration Changes
- Sandbox Strategy & Change Management (the Developer Journey stops here; you continue)
- Approval Process
- Email Templates & Deliverability
- Adoption, Training & Support
Keep as evidence:
- A monitoring cadence and one incident record using the worked triage record: symptom, scope, recent change, containment, owner, and follow-up.
- The Support Workspace checkpoint: the focused app, the activated Case record page, and the checks as an agent and a team lead.
- The case follow-up flow with its fault path and its positive, negative, and bulk tests.
- A reasoned custom metadata versus custom settings decision, the test plan, sign-off, and rollback trigger for the Resolution Notes change, and its release runbook.
- An approval design with its routing documented, an approval notification template in both template systems, and a rollout note with one adoption signal and a support route.
Recovery check: the flow you build in Automation creates a task whenever a case closes, so the agent who owned it checks on the customer a week later rather than trusting a date to be noticed. The failure is a case that closes and no task appears. Work the incident record: confirm the symptom with a fresh case, find the failed interview and the change that preceded it, rehearse restoring the previous flow version, and account separately for the tasks that are missing. Then say what your rollback trigger would have been.
Next included section: Service Cloud Administration, beginning with Build a Support Process.
🎧 Stage 4: Service Cloud Administration
Section titled “🎧 Stage 4: Service Cloud Administration”Stages 2 and 3 had you build a custom app and operate an org. This stage asks you to administer something Salesforce already built. Standard products come with their own objects, automation, and reporting, and the admin’s job is to configure the process inside them rather than recreate it. Service Cloud is the product section on the route because Stage 3 already set up its starting state: you arrive with a support workspace, a follow-up flow, and resolution notes on Cases, and this section turns them into a working support process.
It’s the map’s choose-one stage, with Service Cloud Administration the section on offer today.
Build: the Case support process, finished. Statuses with agreed meanings, queues and access, an assignment rule into triage, an escalation rule, a test mailbox on Email-to-Case, and a backlog report for the team lead.
Core, in menu order:
Keep as evidence:
- The support-process checkpoint: four test cases through assignment and escalation, the email exchange in and out, persona access checks as an agent and a lead, and the reconciled backlog report.
- The status definitions and the decision log behind the queues and rules.
Recovery check: Email-to-Case turns each new email to your support mailbox into a Case. Two addresses are involved: customers write to the mailbox, and your mail provider forwards that mail to the Email Services Address, which Salesforce generates for the purpose. The failure is an email that reaches the test mailbox but creates no case. Send one message straight to the Email Services Address: if that creates a case, Salesforce is working and the fault is in the forwarding. Then work through the chapter’s checks (address verification, forwarding logs, accepted senders, and inbound email errors), keep the original email, prove the fix with a second one, and record which side failed.
Next included section: Salesforce Admin Practice, beginning with the Equipment Request Capstone.
🏁 Stage 5: Salesforce Admin Practice
Section titled “🏁 Stage 5: Salesforce Admin Practice”Everything before this stage built something new. This stage changes something people already depend on. The Equipment Request app has been live for a quarter, IT has reorganised, and Finance wants a second approval over a threshold. You agree the change, move the routing rules into custom metadata, add the escalation stage, prove the existing behaviour still holds, release it through a sandbox with a runbook and a rollback trigger, and hand it over with the evidence another admin would need. It comes last because it draws on the earlier stages together: the access model from Stage 1, the app and its tests from Stage 2, the change discipline from Stage 3, and the product checkpoint from Stage 4 as one of its completion criteria.
Build: Equipment Request, changed on a live org. Routing as data, a Finance escalation stage, an Admin Hold for the request no rule can route, regression against the original acceptance criteria, and a release rehearsed both ways.
Core, in menu order:
Keep as evidence:
- The evidence pack, organised by the completion criteria: change brief, decision log, routing records, change tests, regression results, the unchanged baseline total, incident note, release record, rollback rehearsal, and handover.
- The reviewer’s trace of one under-threshold request, one escalated request, and the one whose team had no routing record, or your own trace a day later from the pack alone.
Recovery check: a request enters the Admin Hold, or the approval submission ends in Error. Follow the capstone’s recovery procedure: repair the configuration, close the original submission, raise a replacement as the requester, and prove one new approval reaches the right approver. Record the original as closed and the replacement as the successful approval; the original was not resumed.
Next: review your evidence below, then choose a direction.
✅ Review your evidence
Section titled “✅ Review your evidence”The journey ends with a review because finishing the chapters isn’t the same as being able to do the work. The measure is what you can show: the builds in your practice org, the decisions you wrote down, and the tests you ran as someone other than yourself. Checking that against a fixed set of criteria separates what you can already do from what you only recognise when you read about it, and that is what tells you where to spend your time next.
The capstone’s completion criteria are the review for the whole path, not only for the change you delivered there, because the capstone is where the evidence from every stage is assembled. Their eight capability rows each trace back to earlier work. The table below shows where each capability is first evidenced on the route, so a gap in the criteria points you back to the stage to revisit.
| Capability | First evidenced | Final evidence |
|---|---|---|
| Discovery and role judgement | Stage 2, the brief and acceptance criteria | Stage 5, the change brief |
| Security and access | Stage 1, Users and Record Access | Stage 5, the persona matrix updated for Finance approvers |
| Data, configuration, and analytics | Stage 1, reports and data management | Stage 2, the import; Stage 5, routing records and the unchanged baseline |
| User experience and adoption | Stage 3, the Support Workspace and the rollout note | Stage 5, the work-item experience for managers and Finance |
| Automation and approvals | Stage 2, the Flow approval | Stage 3, the follow-up flow and approval design; Stage 5, routing and escalation |
| Operations and controlled change | Stage 3, the incident record, test plan, and runbook | Stage 5, the release, rollback rehearsal, and handover |
| Product administration | Stage 4, the support-process checkpoint | Stage 4, the same checkpoint, attached to the capstone’s product row |
| Integrated delivery | Stage 5, the change brief and decision log | Stage 5, the evidence pack and retrospective |
Use the capstone’s Pass, Gap, and Not run marks for each criterion, then record one review decision for the capability. Leave the review open when a required check is Not run or a Gap has not been accepted as a scope change. The stage columns show where to return.
If someone is reviewing your work with you, the criteria and the reviewer’s trace are what they need, because both were written to be read by someone who wasn’t in the org with you.
🎓 After the journey
Section titled “🎓 After the journey”Finishing the journey opens three sensible directions, and the right one depends on where your work is pulling you.
- Go deeper as an admin. Take the reviewed pack back to your own org. Auditing real sharing rules, real automation, and a real sandbox strategy will teach you more than any second reading, and the capstone’s Extend the brief gives you three changes to deliver the same way.
- Move towards code. If declarative tools keep running out of road, Developer Mindset & Toolkit begins the development track. Stage 1 and the opening chapters of Stage 3 are shared with the Developer Journey, so use your evidence when you reach them there.
- Look towards architecture. Understanding the Role of a Salesforce Architect explains where that path leads and what experience it expects you to gather first.
🔄 Keep your learning current
Section titled “🔄 Keep your learning current”When an org upgrade or an unexpected result affects your work, start with 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. Then check the Salesforce Help article for the feature in question, Trust for platform incidents, and the Trailhead Admin career path for how the role itself is moving. Match the guidance to your org’s release, 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 Admin Essentials.