When I first started reading about Salesforce projects, I quietly nodded along every time someone said “the architect will handle it,” while having absolutely no idea what an architect actually did that an admin didn’t. Every guide seemed to assume you already knew the cast. Admin, developer, business analyst, project manager, architect, sponsor. Great. But who are these people, and more importantly, who’s supposed to make the call when a decision needs making?
That gap is the whole reason projects end up with fuzzy accountability. So let’s fix it. Below is every core role on a typical implementation team, what each person really does on a normal workday, and the part almost nobody spells out: who’s actually in charge at each phase of the project.
If you’ve already read our walkthrough of the Salesforce implementation phases (Discovery through Hypercare), this is the companion piece that puts faces to those phases.
Table of Contents
Key takeaways
- A Salesforce implementation team has eight core roles across three families: strategy & delivery, analysis & design, and build & quality.
- Most CRM projects fail for people-and-process reasons, not technical ones, which makes role clarity the cheapest risk reduction available.
- Leadership rotates by phase. The BA and sponsor drive Discovery, the architect owns Design, admin and developer run Build, and the admin carries Go-Live and Hypercare.
- QA and UAT are different jobs. QA is technical testing by the team; UAT is business sign-off by real users.
- Small projects don’t need eight people, but they do need all eight functions covered.
Why getting the team right matters more than the tech
First, let me share an uncomfortable stat that should shape how you staff a project. Research compiled in Johnny Grow’s 2025 CRM Failure Report puts the CRM failure rate at 55% when failure is measured as deployments that didn’t hit their planned objectives. Fifty-five per cent. And the causes are rarely about the software itself. Most post-mortems trace failure back to people-and-process issues: weak adoption, thin change management, messy data. The platform is rarely the villain.
Which means the single cheapest insurance you can buy on a Salesforce project isn’t a fancier feature or a bigger license count. It’s clarity about who owns what. When everyone knows who signs off on testing and who unblocks a stuck decision, you sidestep the ambiguity that quietly kills most CRM efforts.
The flip side is genuinely encouraging if you’re eyeing a career here. An IDC study commissioned by Salesforce projected the Salesforce ecosystem would create 11.6 million jobs worldwide between 2022 and 2028. Demand for every one of these roles is real, even in a hiring market that’s tightened lately.
Salesforce Implementation team at a glance
Eight roles is a lot to hold in your head, so group them into three families:
One quick note before we go deeper: on a small project, one person often covers two or three of these. That’s fine. What matters is that every function has an owner, not that you have eight separate headcount.
Meet the Team: The Eight Core Roles
Executive Sponsor — the one who clears the path
The sponsor is usually a VP or someone in the C-suite. They don’t touch the org, and they’re not in standups every morning. Their job is to fund the project, tie it to a real business goal, and act as the escalation point when something needs authority the team doesn’t have.
Think of them as air cover. When two departments can’t agree on a process and the project stalls, the sponsor walks in and settles it. Don’t confuse them with the project manager. The sponsor is strategic and part-time. The PM is operational and all-in.
Project Manager — the one who owns the timeline
The PM keeps the whole thing moving. Scope, budget, milestones, sprint planning, and holding everyone accountable to dates. When you ask “how’s the project going?”, this is the person who can actually answer.
Most PMs on implementations work for the consulting partner, though large in-house teams hire their own. A lot of them hold a Scrum Master and relevant Project management Certification, since most Salesforce builds run in Agile sprints. Pay reflects how loosely the title is used: Indeed lists a US average of $105,563 for a Salesforce Project Manager (2026), while other trackers land lower.
Business Analyst — the translator
The BA is the person who asks why. Why does the sales team route leads that way? Why does finance need that field? Then they turn those answers into requirements the build team can actually work from, usually as user stories in the “as a [role], I want [action], so that [outcome]” format.
Requirements gathering, process mapping, writing documentation, running requirement sign-offs with the business. That’s the daily rhythm. Salesforce added a dedicated Certified Business Analyst credential in 2022, and it’s now a fairly standard expectation for the role. Average salary is around $110,000
Don’t confuse them with: the consultant or admin. The BA defines what you need and why. Someone else decides how to build it.
Salesforce Consultant — the bridge
The consultant sits between the business and the technology, and on partner-led projects they’re often the client’s main point of contact from kickoff to launch. They scope the work, shape user stories into a working solution, run demos to collect feedback, oversee UAT, and train the users at the end.
Good consultants solve most problems with configuration and only pull in a developer when the requirement genuinely outgrows point-and-click. They tend to be broad, working across multiple products and industries. Indeed lists a US average near $129,367 (2026).
Don’t confuse them with: the architect. A consultant focuses on making the solution fit the business need in front of them. The architect worries about whether that solution still stands up in year three.
Solution / Technical Architect — the one thinking about year three
This is the senior technical authority on the project. The architect owns the big structural decisions: the data model, the security and sharing framework, integration strategy, and the risks that come with large data volumes. When someone proposes a shortcut that’ll paint the org into a corner later, the architect is the one who catches it.
Salesforce splits this into two official credentials that feed the top of the ladder. Per Salesforce’s own architect credential pages, the Application Architect is an expert in native platform features like data modeling and sharing, while the System Architect focuses on integration and securing access between systems. Both are prerequisites for the Certified Technical Architect (CTA), the ecosystem’s most demanding credential, which requires passing a live review board and carries a $4,500 exam fee. Genuine CTAs are rare, and their scarcity shows up in the pay: Glassdoor reports a US average of $143,529 for architects, with senior specialists well above that.
Salesforce Administrator — the backbone
If any single role is the heart of an implementation, it’s the admin, partly because they’re usually the one who stays long after the consultants leave. Admins build with clicks, not code: creating objects and fields, configuring flows and page layouts, managing user access and security, fixing bugs, and keeping the org current through Salesforce’s three yearly releases.
The Salesforce Certified Administrator exam is the front door to the entire ecosystem and covers the everyday features used to keep an implementation running. ZipRecruiter’s US average sits near $98,862 (2026).
Don’t confuse them with the developer. If someone builds a Flow to automate a process, that’s admin work. If someone writes an Apex trigger to do it, that’s developer work.
Salesforce Developer — the one who writes code when clicks run out
Developers extend Salesforce when configuration hits its ceiling. They write Apex classes and triggers (with the test coverage Salesforce requires before you can deploy), build custom interfaces with Lightning Web Components, and wire the platform up to other systems through APIs.
Credentials here run Platform Developer I and, for the more advanced programmatic work, Platform Developer II. Per Salesforce’s PD I page, the certification validates that you know how to build custom logic and when to reach for code versus a declarative tool, which is honestly half the skill. Built In reports a US average base of $113,427 (2026).
QA / Tester — the one who breaks it before your users do
The tester’s job is to find the problems while there’s still time to fix them cheaply. They define test strategies, write and execute functional, regression, and integration tests, and record every defect in such detail that a developer can reproduce it.
One distinction is worth planting firmly, because beginners mix these up constantly: QA is not UAT. QA is technical validation done by the delivery team. UAT (user acceptance testing) is the business signing off that the thing actually does what they asked for. The final UAT call belongs to the business process owners, not to QA. A good tester supports that process; they don’t test on the users’ behalf.
Who leads each phase (the part nobody explains)
Here’s the mental model that made all of this finally click for me. No single role runs the entire project. Leadership rotates, on purpose, as the work changes shape.
A little colour on a few of those. Discovery should end with a signed-off blueprint (requirements, data plan, integration scope, success metrics) that every later phase points back to. Design is the architect’s moment, because the object and security decisions made here decide how maintainable the org is for years. Go-Live is the cutover event itself, with the sponsor visible so the business feels the weight behind it. And Hypercare is the heightened-support window right after launch, usually four to six weeks, where the team stays close, does daily check-ins, and squashes issues fast while real users settle in.
The takeaway: if you ever can’t figure out who owns a decision, look at which phase you’re in.
“But do I need all eight?” — right-sizing your team
Short answer: probably not as separate people, especially early on.
On a small, single-cloud project that’s mostly configuration, a strong admin or an experienced consultant can genuinely wear the BA, admin, and trainer hats at once. Plenty of successful implementations run lean. The thing to protect isn’t headcount, it’s coverage. Run down the three families and check that strategy, analysis, build, and quality each have a name next to them. If any of those four has nobody attached, that’s your highest-risk gap, and it’s worth fixing before you write a line of anything.
You need dedicated specialists when complexity climbs. Multi-cloud rollouts, heavy integrations, or large data volumes are the point at which a dedicated architect and developer stop being a luxury and start being the reason the project doesn’t fall over.
Final Thoughts
Now that you can tell the cast apart, pick the one you’d actually want to be. If a specific role in this list made you lean forward (maybe the admin’s build-everything variety, or the architect’s long-game thinking), that’s worth following up on. Head to our role-specific career guides to see the certification path and day-to-day reality of the one that caught your eye, and read the implementation phases article alongside this one so you can watch these roles in motion from Discovery all the way to Hypercare.
Frequently Asked Questions (FAQ)
The eight core roles are executive sponsor, project manager, business analyst, consultant, architect, administrator, developer, and QA tester. On smaller projects, one person often covers several of these, but each function still needs an owner.
An admin builds with configuration (“clicks, not code”): fields, flows, page layouts, security. A developer writes code (Apex, Lightning Web Components) when a requirement is too complex for declarative tools. Building a Flow is admin work; writing an Apex trigger is developer work.
No. A consultant focuses on shaping a solution that fits the immediate business need, usually through configuration. An architect owns the bigger technical picture, making sure the solution is scalable, secure, and still sound years down the line.
It depends on the phase. The project manager owns day-to-day delivery throughout, but the executive sponsor holds strategic authority and final escalation power. No single person leads every phase, which is by design.
There’s no fixed number. A small, single-cloud project might run with two or three people covering multiple roles. Complex, multi-cloud, or integration-heavy projects justify dedicated specialists, especially a separate architect and developer.
The BA gathers and clarifies requirements, maps existing business processes, and translates what the business needs into user stories the build team can work from. They define what to build and why, leaving the how to the admin, consultant, or developer.
Akanksha Shukla
Akanksha is a Content Writer at SalesforceTrail.com, contributing educational content that supports Salesforce professionals in learning, growing, and advancing their careers within the Trailblazer ecosystem.
- Akanksha Shukla
- Akanksha Shukla
- Akanksha Shukla
- Akanksha Shukla
