Developer or Admin? Why your Salesforce resume can't be both at once

Two people can both say they "work in Salesforce" and mean almost opposite things. One lives in Flow Builder, page layouts, and the sharing model; the other lives in Apex, Lightning Web Components, and API callouts. A recruiter screening for one role is looking for a specific set of signals — and a resume that blurs the two reads as neither. The single most common self-inflicted wound on a Salesforce CV is trying to be an Admin and a Developer on the same page. Pick a lane per application, and lead with it.

The core split: declarative vs programmatic

Everything flows from one distinction the ecosystem takes seriously:

• Administrators solve problems declaratively — "clicks, not code." They configure the platform: Flow Builder, validation rules, page layouts, approval processes, the role hierarchy and sharing model, permission sets, reports and dashboards, data quality, and user management. The craft is combining standard features creatively to meet a business need without writing code.
• Developers solve problems programmatically — they reach for code when configuration runs out of road: Apex, Lightning Web Components, SOQL/SOSL, JavaScript, and integrations via REST/SOAP APIs, Platform Events, or MuleSoft. The craft is building scalable, tested custom functionality the standard tools can't.

A hiring manager for an admin role and one for a developer role are reading for different vocabulary, different achievements, and different proof. Your resume has to speak the right one.

What an Admin resume has to foreground

Lead with declarative depth and the scale of the org you keep healthy:

• Automation: Flow Builder is the keyword that matters now — and "migrated legacy Workflow Rules and Process Builder to Flow" is a strong, current phrase. Name the flows and what they automated.
• Security & access: the role hierarchy, sharing rules, permission sets, and profiles — the sharing and security model is core admin territory.
• Data quality & stewardship: deduplication, validation rules, data imports, field governance.
• Insight & adoption: reports, dashboards, and the user base you support.

Before: "Managed Salesforce for the sales team."

After: "Owned a 300-user Sales Cloud org: built 40+ Flows to automate lead routing and approvals, tightened the role hierarchy and sharing rules, and cut duplicate accounts by 60% with validation rules and a dedupe process."

What a Developer resume has to foreground

Lead with what you built, shipped, and tested:

• Apex, done right: classes and triggers, bulkification, asynchronous patterns (Batch, Queueable, Future), and governor-limit awareness. Recruiters screen hard on Apex when the posting mentions it.
• Front end: Lightning Web Components (and enough JavaScript/HTML to back them up).
• Data & queries: SOQL and SOSL.
• Integration: REST/SOAP callouts, Platform Events, middleware like MuleSoft.
• Quality: Apex test coverage and a testing discipline — a number here is a strong signal.

Before: "Developed on Salesforce."

After: "Built and bulkified Apex triggers plus 15 Lightning Web Components for a Service Cloud rollout; integrated billing through Platform Events and a REST callout, and held Apex test coverage above 90%."

Notice what both rewrites share: they name the specific tools and attach a number. That is the same principle behind quantifying impact and covering the right ATS keywords — it just points at a different toolset depending on the lane.

Both roles now touch Agentforce

The AI shift is blurring the edges, not erasing them. Admins increasingly build Flow-based agent actions, while developers write Apex-based agent actions and design the agent architecture. Either way, if your target role mentions Agentforce, Einstein, or Data Cloud, put your version of that work on the page — it is fast becoming a differentiator, and it still reads differently for each lane.

If you genuinely do both

Plenty of strong Salesforce professionals are hybrids — the admin who writes Apex, the developer who is fluent in Flow. That is an asset, but it is not a licence to send one blended resume everywhere. Do this instead:

• Tailor per application. For an admin role, lead with declarative work and let code be supporting evidence of depth. For a developer role, flip it. The job description tells you which layer to lead with.
• Don't dilute the headline. A summary that tries to claim both equally reads as junior at both. Anchor it to the role you are applying for, and mention the second skset as range, not as a co-lead.
• Let the certifications reinforce the lane. Administrator-track versus Platform Developer credentials send a clear signal about where you sit — see the certification roadmap for sequencing.

Make tailoring cheap

Maintaining two (or three) tailored variants by hand is exactly the friction that pushes people toward one generic CV. In the SFCV builder your full history lives in one place, so an admin-leaning and a developer-leaning version derive from the same source instead of drifting apart — and the built-in ATS Score panel lets you paste a specific posting and confirm the resume actually carries that lane's vocabulary before you send it.

Same platform, two different arguments for hiring you. Decide which one each role wants to hear, lead with it, and back it with work you shipped — and stop asking a single page to be an Admin and a Developer at the same time.