A Salesforce administrator runs the org day to day: users, access, fields, Flows, reports and small changes. A developer handles what clicks cannot, writing Apex, Lightning Web Components and integration code. An architect designs the structure everything else sits on, including the data model, sharing and integrations. A consultant turns business processes into a Salesforce design and leads the project. Most companies need an admin continuously and the other three when the work calls for them.
The four roles side by side
Job titles in the Salesforce world are used loosely, so it helps to define each role by the decisions it owns rather than by what appears on a résumé. The table below reflects how the work usually divides on a well-run team.
| Administrator | Developer | Architect | Consultant | |
|---|---|---|---|---|
| Owns | Daily operation and small, declarative changes | Custom code and technical integration work | Structural design decisions and technical standards | Requirements, solution design and delivery of a project |
| Typical work | User setup, permission sets, fields, layouts, Flows, reports, data imports | Apex triggers and classes, Lightning Web Components, API integrations, test classes | Data model, sharing model, integration patterns, org strategy, scale and limits | Discovery workshops, process mapping, configuration plans, testing and training |
| Main question | Is the org working for users today? | How do we build what configuration cannot? | Will this design still hold in three years? | What should we build, and in what order? |
| Salesforce credentials | Platform Administrator, Platform Administrator II | Platform Developer | Application Architect, System Architect, Technical Architect | Product consultant certifications, such as Agentforce Sales Consultant |
| How often you need it | Every week | In bursts, tied to specific builds | At key decisions and periodic reviews | For projects and major changes |
Credential names change. In July 2026 Salesforce renamed several consultant certifications, so the Sales Cloud Consultant became the Agentforce Sales Consultant and the Service Cloud Consultant became the Agentforce Service Consultant. The Technical Architect credential is earned through a review board, and the Application Architect and System Architect credentials are the prerequisites for attempting it.
Where the lines blur
The boundaries are softer than the table suggests. A strong admin building a record-triggered Flow with loops, subflows and fault paths is doing logic design that looks a lot like programming, and should follow the same discipline: a sandbox, tests and a deployment plan. Many developers can configure as well as any admin. Salesforce's refreshed Platform Administrator exam now includes an Agentforce section, a sign that the admin role is expanding into configuring and supervising AI features.
The architect and consultant roles overlap too. On a smaller project one experienced person often does both: running discovery with the business, then making the design calls. On larger programs they separate, because the consultant is focused on what each team needs, while the architect is focused on how those needs fit together without creating conflicts in data, security or performance.
A useful test is reversibility. Work that is cheap to undo, such as a new report or a picklist value, belongs with the admin. Work that is expensive to undo, such as splitting an object in two, choosing between one org or several, or deciding which system owns customer records, deserves an architect's review before anyone builds it.
When you need each role
- An administrator, from the day you have users. Someone has to own access, answer questions and keep the configuration tidy, even if that is a part-time responsibility at first.
- A developer when a requirement needs custom logic, a user interface the standard components cannot provide, bulk processing, or an integration without a ready-made connector.
- An architect before a new implementation is designed, before connecting a major system such as your ERP, when considering a second org or a merger of two, and when performance or platform limits start causing failures.
- A consultant when you are adding a cloud, redesigning a sales or service process, or starting a project large enough to need discovery, a plan and someone accountable for delivery.
The costly mismatches run in both directions. Asking an admin to design an integration architecture puts a decision with long consequences on someone without the training to see them. Hiring a full-time developer to run a mostly declarative org leaves you paying for skills that sit idle while basic requests wait. We once worked with an investment advisor whose principal had been trying to configure its marketing platform alone, alongside strict archiving and supervision rules; the business problem was clear, but it needed specialist setup, not more evenings from a senior executive.
How the roles combine in a team
Team shape follows org complexity more than company size. A single-cloud org with a few dozen users can often run with one admin and occasional outside help. An org with several clouds, integrations and custom code needs a standing group, often organized as a center of excellence, with clear ownership of each type of decision.
| Org profile | Internal roles | Brought in as needed |
|---|---|---|
| One cloud, mostly standard configuration | Part-time or full-time admin | Consultant for new projects; developer for occasional builds |
| Multiple clouds, a few integrations | Admin, plus a business owner who sets priorities | Developer, architect review, consultant for major changes |
| Heavy customization, many integrations, AI agents | Admins, developers, and an internal architect or technical lead | Specialist architects for integration, security or data; consultants per project |
Whatever the shape, two things hold the roles together. First, one person on your side decides priorities and accepts finished work; without that owner, admins and developers end up taking requests from whoever asks loudest. Second, shared standards, such as naming conventions, a single approach to automation per object and a documented release process, let people in different roles change the same org without breaking each other's work.
The roles in a managed services model
Few companies can justify employing all four roles full time. Managed services exists to fill that gap: you pay for an agreed monthly scope and draw on an admin, developer, architect or consultant according to what each request needs. A request to add users goes to an admin; a failing integration goes to a developer; a proposal to restructure accounts gets an architect's review first.
This works best when the provider routes work by skill rather than sending everything to whoever is free, and when you can see who handled each item. Ask how a request is triaged, who decides that a change needs architectural review, and how that review is documented. When comparing providers, count certifications by role rather than in total; for context, Abstrakt became a Salesforce Consulting Partner in 2017, and its U.S.-based consultants hold 150 in all.
Managed services does not remove the need for someone internal. You still need an owner who knows the business, sets priorities and approves changes, and many companies keep an internal admin for the daily flow of questions while the provider supplies the deeper skills. The arrangement that tends to fail is the one where nobody inside the company understands the org and every question, however small, becomes a ticket.
Choosing what to hire and what to source
- Hire for the work that is constant and depends on business context, which is usually administration and product ownership.
- Source the work that is intermittent or highly specialized, which is usually architecture, complex development and integration.
- Keep documentation, credentials and metadata under your company’s control, whoever does the work.
- Review the mix once a year: a growing backlog of development or integration requests is a sign the balance has shifted.
