A Salesforce project rarely needs “a Salesforce person”. It needs a mix of skills, and that mix changes as the project moves from planning to build, go-live, and support. When the job brief only says “Salesforce resource”, the shortlist gets too wide, and the first few weeks go into finding out who actually fits. This guide explains the main Salesforce roles in simple words: what each person does and when you need them on the project. It is written for CIOs, CRM programme leads and IT heads who are planning a new rollout or growing a support team. We also show how a Salesforce recruitment agency uses this clarity to put the right profiles in front of you.
The core Salesforce roles
Administrator. The admin runs the platform day to day. That means users and access, reports and dashboards, automation through Flow, and keeping the data clean. They also handle the three Salesforce releases every year. In many companies, the admin is the person who knows the org best.
Developer.
The developer builds what configuration cannot. They write Apex code, build Lightning Web Components and connect Salesforce with other systems. Good developers also write proper tests and keep the code easy for the next person to read. If you plan to hire Salesforce developers in India, ask to see real project work, not only certificates.
Functional Consultant. The consultant is the link between the business and the build team. They run requirement workshops, map the processes, write user stories and support user testing. The best ones know when to configure, when to customise and when to suggest a simpler process.
Technical Architect. The technical architect owns the design of the platform. That covers the data model, security, integrations and the standards the developers follow. They also decide whether different business units share one org or need separate ones.
Solution Architect. The solution architect looks at the bigger picture: how Salesforce works with your ERP, marketing tools and data platforms, and which Salesforce clouds you really need. On smaller projects, one experienced architect often covers both the solution and technical side.
Salesforce roles at a glance
Role | Main focus | When you need them |
Administrator | Running the platform | Go-live and everyday support |
Developer | Custom build | When configuration is not enough |
Functional Consultant | Business fit | Discovery, design and testing |
Technical Architect | Platform design | Large or complex orgs |
Solution Architect | Overall solution | Start of any major programme |
Supporting roles for bigger programmes
Larger implementations usually add a few more specialists.
Integration developer: builds the connections between Salesforce and the ERP, HR or billing systems.
Release manager or DevOps engineer: manages how changes move from testing to the live org.
Data migration specialist: moves, cleans and loads your old data into Salesforce.
QA tester: tests every release and supports user testing.
Business analyst: helps the consultant document processes and manage requirements.
Clouds and specialisations matter
Salesforce is a family of products, not one product. Sales Cloud, Service Cloud, Experience Cloud, Marketing Cloud and Revenue Cloud each have their own setup and way of working. Marketing Cloud in particular runs quite differently from the core platform, so a strong core developer will still need time to settle in.
That is why you should name the cloud as well as the role. A Service Cloud consultant who has set up case management and routing will help a contact centre project far more than someone who has worked only on Sales Cloud.
Newer areas like Data Cloud and Agentforce are also creating demand. Since these are new, look for hands-on project work instead of long years of experience.
Who you need at each stage
Discovery and design: the solution architect and functional consultant define the scope and the target design.
Build: developers, an admin, and an integration developer join, and the technical architect reviews the work.
Testing and data migration: the QA tester and migration specialist take the lead, and the consultant guides business users through testing.
Go-live: everyone follows a clear plan with one owner for each step.
Support: the team usually shrinks to an admin and one or two developers who handle fixes and small changes.
A sample team for a first Salesforce project
For a mid-size rollout of Sales Cloud and Service Cloud, a simple team often looks like this: one solution architect for the early design phase, one functional consultant, two developers, one admin and one QA tester. The architect can step back after design and return for reviews. If you also need to connect an ERP, add an integration developer for the build phase.
This is only a starting point. Your clouds, number of users and timeline will change it, but it gives you a realistic base to plan your budget and your hiring calendar, instead of guessing.
What to check beyond certifications
Certifications are a useful first filter. But the interview should be about what the person has actually delivered.
- Admins: ask how they would redesign user access, or how they moved old automation to Flow.
- Developers: ask how they handled a large data job and how they tested and released their code.
- Consultants: ask about a requirement that did not fit standard features and how they solved it.
- Architects: ask about one design decision and the trade-offs they weighed.
Ask everyone to walk you through one recent project: the cloud, the team size, their own role and what went live. Clear answers tell you more than the number of badges.
It also helps to give the India team complete modules instead of small, separate tasks. Ownership keeps people engaged and reduces the need for real-time communication.
Common hiring mistakes to avoid
A few mistakes show up again and again. Companies ask for “a Salesforce developer” without naming the cloud, so the profiles they get are too mixed. They hire a developer when the real gap is a consultant, and the build starts before anyone has agreed what to build. Some bring in the full team too early and pay for months of waiting. Others leave the architect role open and let each developer take their own design decisions.
A short, clear role brief fixes most of this. Name the cloud, the project stage, the team size and the main outcome you need from the hire. Each one is much cheaper to fix early.
Permanent, contract or a project team
The right hiring model depends on how long you need each skill. Implementations often suit contract hiring, because the team is bigger during build and testing and smaller after go-live. Roles that own the platform, like the admin and the lead developer, usually work better as permanent hires, since they build up knowledge of your org over time. Many companies use a mix of both. They hire a permanent admin and lead developer, then bring in contract people for the busy phases. This is where Salesforce staffing in India works well, because you can add skilled people when the project needs them and scale down after.
How a Salesforce recruitment agency helps
A specialist Salesforce recruitment agency starts with the project, not the job title. It asks which cloud, which stage and which role, and then checks real project experience before sharing any profile. So the people you interview already match the work.
It also helps if you share a few basics in your brief: the cloud, the project stage, the team size, the timeline and whether the role is permanent or contract. With these details, a recruiter can shortlist faster and you spend less time on interviews that go nowhere.
At Bhavishyam Consulting, our recruiters work on Salesforce hiring every day. We help companies hire admins, developers, consultants, architects and specialist roles on permanent, contract or project terms.