The Salesforce Career Map Nobody Publishes

Most Salesforce career advice presents the roles as a progression: Admin, then Developer, then Architect. Work hard, collect certifications, move up. The problem with this framing is that it is wrong — and the people repeating it either do not know what these roles actually involve or have a reason not to say.

Admin, Developer, Business Analyst, Consultant, and Architect are not rungs on a ladder. They are different jobs. Different day jobs, different ceiling levels, different skill profiles, and increasingly different futures as AI changes what each role actually does. Getting this right at the start saves years of moving in the wrong direction.

The Admin role

An Admin's job is to keep an org running and make it do new things when the business asks. In practice, this means handling user requests, building flows, maintaining data quality, managing permissions, deploying changes, and answering the question "why isn't this working?" several times a day. It is an operations role as much as a technical one.

The ceiling depends on the org. A large enterprise admin who owns a genuinely complex org — multiple business units, heavy integrations, deep automation — is doing real work with real authority. A small-org admin who has hit the limit of what the business needs is stuck, because there is only so much optimisation you can do on a 50-user org with three flows.

AI is changing this role significantly. A large portion of routine admin work — building simple flows, writing field descriptions, generating reports, troubleshooting common errors — is now assistable by AI. The admins with a future are the ones developing judgment about what to build and when, not just technical skill at building it.

The Developer role

Salesforce development means Apex, LWC, integrations, and the architecture decisions behind them. It is a software engineering role on a proprietary platform. The day job is different from admin: you spend more time in code than in clicks, more time thinking about data models and governor limits than user permissions and flow logic.

The developer path has a higher technical ceiling and a larger external job market than the admin path. A strong Salesforce developer can move between orgs, into consultancies, into ISV (independent software vendor) product roles, or into platform engineering at companies with serious Salesforce operations. The skills transfer further.

The risk is over-investing in Salesforce-specific technical depth without building portable engineering fundamentals. Apex is Java-adjacent, but it is still a platform-specific skill. The developers who are hardest to replace are the ones who understand what Salesforce does well versus what should be handled outside the platform — and can have that conversation with an architect without faking it.

The Business Analyst role

The BA is the translator between what the business says it wants and what should actually be built. This role gets underestimated by people who have never done it, and overestimated by people who do it badly. A good BA produces a requirements document that a developer can implement without surprise late-stage changes. A bad BA produces a wish list that causes a three-month rebuild halfway through delivery.

The BA path lends itself to people who are stronger on communication and problem definition than on building things themselves. It is a legitimate senior path — senior BAs and Business Architects at large consultancies earn serious money and work on projects admins will never see. The limitation is that it is heavily dependent on the quality of the team around you. A BA on a well-run project adds enormous value. A BA on a project with no real delivery structure ends up being held responsible for every failure without the authority to prevent any of them.

The Consultant role

Consulting is a delivery role, not a technical seniority level. It is worth separating it from the others because the job involves the whole project, not just one function. You are responsible for scoping, requirements, solution design, delivery management, client relationship, and quality — often simultaneously, often with a team of more junior people who know more about the specific technical components than you do.

Senior consultants and delivery leads earn the most in the Salesforce ecosystem — not because they know the most, but because they own the outcome and have the client relationship. The career risk is that it is hard to maintain technical depth when you are also running delivery. Many senior consultants become increasingly dependent on their team for anything technical, which limits their options if they ever want to move back into a hands-on role.

The Architect role

Architect means different things in different contexts. A Solution Architect owns the design of a single implementation — the data model, integration approach, automation strategy, and the reasoning behind each decision. A Technical Architect has hands-on Apex and integration depth and can validate that what was designed is actually buildable. An Application Architect, at the certification level, is expected to hold both together across multiple Salesforce clouds.

What architects have that other roles do not is pattern recognition across many implementations. You cannot fake this. The difference between a good architect and an expensive admin with a certification is whether they understand why certain designs fail at scale, why certain integration approaches create maintenance problems over time, and where the edge cases are before the edge cases appear. That comes from exposure to real org complexity, not from passing exams.

How to decide

The question is not "which role pays more" — they all pay well at the senior end. The question is which day job you want, and which skills you are genuinely willing to build deeply over several years.

Three questions worth sitting with honestly:

• What do you actually do when work is going well? Not what you think you should enjoy — what you genuinely lose track of time doing. If it is fixing a broken flow and figuring out why it failed, admin. If it is writing code and solving technical puzzles, developer. If it is getting people in a room to agree on what to build, BA or consulting. If it is designing a system and thinking about what breaks at scale, architect.
• What is your tolerance for ambiguity? Consulting and architecture require operating with significant ambiguity — requirements that change, clients who do not know what they want, problems with no obvious right answer. Admin and development tend to have clearer success criteria. Neither is better. They suit different people.
• Do you want depth or breadth? Deep technical specialists (strong developers, technical architects) have portable, defensible skills in a smaller market. Generalist practitioners (consultants, BAs) move faster and earn more earlier but are harder to differentiate at the senior end. Both paths work. Trying to do both at once produces neither.

If you are genuinely undecided, start in the role closest to what you already know, and pay close attention to which parts of the adjacent roles you find yourself doing voluntarily. That is the direction.

Pick the path that matches how you actually spend your time when the work is going well. That is more reliable signal than any career advice.