SFDC is an abbreviation for Salesforce.com — the company's original domain name and still the base of its platform URLs, API endpoints, and developer tooling references. The abbreviation shows up across job postings, partner listings, and internal org documentation, often interchangeably with "Salesforce."
An SFDC consultant is a consultant who works on the Salesforce® platform. But that framing alone is close to useless. The Salesforce ecosystem spans Sales Cloud, Service Cloud, Marketing Cloud, Revenue Cloud, Commerce Cloud, and a dozen other products, plus the underlying platform where Apex code and Lightning Web Components run. An SFDC consultant might specialize in any of these, or in the connective tissue between them.
This guide clarifies what SFDC consultants actually deliver, how the role sits relative to adjacent roles, typical engagement shapes, and how to evaluate one for a real project.
SFDC consultant vs administrator vs architect
These 3 roles are frequently conflated in hiring and vendor selection.
Salesforce administrator: Works declaratively within the Salesforce platform — creates custom objects and fields, builds Flow automation, manages permission sets, configures page layouts, and handles user management. Admins do not write code. Their work is bounded by what the platform exposes through its point-and-click configuration interface. An admin is well-suited for initial org setup and ongoing configuration changes that do not require custom development.
SFDC consultant: Works at the boundary of declarative and programmatic. They configure Salesforce like an admin but also write Apex classes, triggers, and batch jobs; build Lightning Web Components; and design integration architecture. They build what the admin interface cannot handle and what the architect has specified. This is where the majority of implementation project hours actually sit.
Salesforce architect: Works at the platform strategy level — data model design, sharing model decisions, integration topology, scalability planning, and governance frameworks. Architects typically do not write production code day to day; they review it and set direction. In smaller engagements, the consultant and architect role collapse into the same person.
The SFDC consultant is the execution layer. Most Salesforce projects are primarily consultant work.
What SFDC consultants ship
The day-to-day output of an SFDC consultant varies by engagement type but falls into consistent categories:
Apex development: Custom server-side code running on Salesforce's platform. Triggers that enforce complex data validation, batch jobs that process large record sets overnight, scheduled jobs for data operations, REST callout classes that integrate with external APIs. These all require Apex.
Lightning Web Components: Custom UI built in JavaScript and HTML that renders inside Salesforce Lightning Experience or Experience Cloud portals. When the standard Salesforce UI does not fit the workflow, LWC provides a custom interface that integrates natively with Salesforce data.
Integration work: Connecting Salesforce to external systems using REST, SOAP, or Bulk APIs. An SFDC consultant builds the Salesforce side of the integration — callout classes, Connected App configuration, OAuth flows, error handling, and retry logic. Middleware platforms such as MuleSoft or Boomi may be involved, but the Salesforce integration layer is the consultant's domain.
Flow and process automation: For logic that can be handled declaratively, a skilled consultant uses Flow rather than Apex — it is easier to maintain and does not require a developer for future changes. Knowing when to write code and when to use Flow is a core competency that distinguishes a strong SFDC consultant from one who defaults to code for everything.
Data migration: Moving records from a legacy CRM, spreadsheet, or external system into Salesforce. Includes data mapping, transformation logic, deduplication strategy, and validation. Large migrations use the Bulk API to handle governor limit constraints.
Org cleanup and audit: Reviewing an existing Salesforce org for accumulated technical debt — conflicting automation (triggers fighting with Flow), unused custom objects and fields consuming storage, permission set sprawl, outdated integrations still running. Cleanup projects are among the most underrated engagements because they pay for themselves: reduced support burden, faster new feature delivery, lower risk of regressions.
Typical engagement examples
Sales Cloud initial deployment: 12 weeks, 3-person team (consultant, admin, project manager). Deliverables include lead management process, opportunity pipeline, quote generation via standard quoting tool, and dashboard suite. Integration with marketing automation platform. User training and champion program.
Custom CPQ build with Apex: 16-20 weeks, 2 Apex developers plus solution architect. Complex product catalog with nested bundles, pricing rules that cannot be handled by standard CPQ, custom quote PDF template, integration with ERP for order fulfillment. Full regression test suite.
Org audit and cleanup: 6-8 weeks, 1 senior consultant. Deliverables: technical debt inventory (conflicting automation, unused objects, permission gaps), prioritized remediation plan, and cleanup implementation for high-priority items. Often precedes a major new feature build where existing debt would otherwise block delivery.
ERP integration: 10-16 weeks, 1-2 integration engineers. Bi-directional sync between Salesforce and NetSuite or SAP: opportunity-to-order handoff, customer record sync, product catalog alignment, invoice status updates. Includes failure monitoring and retry infrastructure.
Managed services retainer: Ongoing, 10-40 hours/month. Covers user requests, configuration changes, bug fixes, new feature implementation, platform update testing, and production issue response. The consultant maintains deep org knowledge over time, which accelerates every task compared to a project team starting cold.
How the daily work breaks down
An SFDC consultant on a typical implementation spends time roughly as follows:
- Development (Apex, LWC, Flow): 40-50% — writing, testing, and reviewing code and automation
- Configuration and data work: 20-30% — custom objects, permission sets, data migration runs
- Discovery and design: 10-15% — requirement sessions, data model documentation, integration architecture review
- Testing and QA: 10-15% — unit tests in Apex (75% coverage minimum for production deployment), integration testing, user acceptance testing
- Communication: 5-10% — status updates, stakeholder demos, requirement clarification
The ratio shifts with project phase: discovery-heavy at the start, development-heavy in the middle, testing and user acceptance-heavy near go-live.
What SFDC consultants do not do
Understanding the boundaries is as useful as understanding the scope:
- They do not set platform strategy. Architecture decisions about data model design, multi-org vs single-org, sharing model approach — those belong to a Salesforce architect. A consultant implements the strategy; they should not be solely responsible for defining it on a complex implementation.
- They do not own user adoption. Building a working Salesforce org and ensuring users actually use it are separate problems. Adoption is a change management function, not a development function.
- They do not replace an administrator. An SFDC consultant who spends half their time on routine user requests and permission changes is expensive overhead. If your org needs day-to-day configuration support, hire or designate an admin alongside the consultant.
- They do not substitute for a clear requirements owner. The consultant builds what is specified. If the business requirements are unclear or contested internally, no consultant can resolve that — requirements ownership sits with the client.
How to vet an SFDC consultant
These 5 questions surface genuine production experience:
- "Walk me through an Apex trigger you built. What governor limits did you have to work around, and how?"
- "Tell me about a Salesforce integration you built that failed in production. What broke and what did you change?"
- "For a requirement involving complex discount logic, when would you use Flow vs Apex vs a managed package?"
- "What is your test coverage approach — what makes a good Apex test class vs a test class that just hits coverage thresholds?"
- "Walk me through how you approach an org audit. What do you look for first?"
The production failure question (question 2) is the highest-signal item. A consultant who has never recovered from a real production failure has not been in high-stakes engagements. The answer should describe a specific failure mode, how it was detected, and what architectural change prevented recurrence.
A 2-week paid trial on a well-scoped piece of work — a specific Apex task, a Flow automation, an integration proof-of-concept — gives you more actionable signal than any interview process.
The Sapota team includes SFDC consultants with production Apex, LWC, integration, and org cleanup experience across Sales Cloud, Service Cloud, and Marketing Cloud. If you are planning a Salesforce project or need a second opinion on an existing org, reach out to the team.
