Salesforce administrator screening questions: org complexity, Flow, security and certifications
On this page
- Admin, business analyst, consultant or developer: place the candidate
- Org complexity: the numbers that set the level
- Automation: Flow depth and the legacy tools
- Security and access: where admin mistakes cost the most
- Releases, data and the business side
- Certifications: names, maintenance and verification
- How Salesforce profiles overstate the work
- Logistics, knockout checklist and scorecard
- Questions people ask
Salesforce administrator screening questions should find out how complex an org the candidate has run and what they changed in it themselves. Ask how many users and which clouds, how many custom objects and record types, which Flows they built and what broke, how access was controlled, how changes moved from sandbox to production, and how their certifications stand today. An admin with real ownership talks about a Flow that hit a limit, a permission set that exposed the wrong records, or a data load they had to roll back. An inflated profile lists clouds and badges with no change they can walk you through.
There is no general engineering screen that covers this well. Software engineer phone screen questions tests people who write application code, and data analyst phone screen questions covers people who analyze data. A Salesforce admin configures a business system many teams depend on, so this bank tests org scope, declarative automation, security, release discipline and the business side. For contract admins, add IT contractor screening questions.
Admin, business analyst, consultant or developer: place the candidate
| Role in practice | What the week produces | Question that places them | Common mismatch |
|---|---|---|---|
| Salesforce administrator | User setup, fields, layouts, reports, Flows, permission changes, release testing | "What did you change in the org last week?" | A power user who builds reports, titled admin |
| Senior or lead admin | Org design decisions, release management, junior admins, governance | "Who approved changes, and who decided how the data model grew?" | The only admin at a small company, described as leading |
| Salesforce business analyst | Requirements, user stories, process maps, testing | "Did you build the solution or specify it?" | Wrote stories others built, described as configuration |
| Implementation consultant | Several client orgs, discovery, build, go-live | "How many implementations, how long each, and what did you build?" | Short project stints listed as long ownership |
| Salesforce developer | Apex, Lightning Web Components, integrations | "What share of your changes needed code, and who wrote it?" | Edited existing Apex once, listed as developer |
Org complexity: the numbers that set the level
An admin at a 40-user company on Sales Cloud and an admin at a 4,000-user company with Service Cloud, Experience Cloud and three integrations are doing different jobs. You do not need to judge the numbers; you need the candidate to know them and to match them to the client's org.
- "Roughly how many users, and how many were you personally supporting?" Strong: a number and a split, such as "about 900 licensed users, I handled sales and support; another admin handled finance." Red flag: does not know.
- "Which clouds and products were in use, and which did you configure yourself?" Strong: separates what they configured from what existed, for example Sales Cloud and Service Cloud configured, CPQ owned by a partner. Red flag: every cloud, equal depth.
- "How many custom objects and record types, roughly? Which did you add?" Strong: an estimate and one object they designed with the reason. Red flag: never added an object.
- "What systems were integrated with Salesforce, and what was your role when a sync failed?" Strong: names the systems (ERP, marketing automation, billing) and a failure they diagnosed. Red flag: integrations were a mystery handled elsewhere.
- "How many sandboxes, and what kind?" Strong: knows the types in use and what each was for. Red flag: changes made directly in production as normal practice.
- "Was it one org or several? Any org merge?" Strong: a clear picture, and an honest part in any merge. Red flag: "one org" when the company clearly had several business units with separate orgs.
Automation: Flow depth and the legacy tools
Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025, and recommends Flow, per its end-of-support notice (as of September 2026, existing automation keeps running but gets no bug fixes). That makes Flow the center of this part of the screen, and a migration story a useful signal.
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| Tell me about the most complex Flow you built. What triggered it and what did it do? | The business need, the trigger (record-triggered, scheduled, screen flow), the main steps, and who used it. | Only simple field updates, described as "complex automation." |
| Tell me about a Flow that failed in production. | The error, how they found it (fault emails, debug logs), the fix, and what they changed: fault paths, bulk testing, entry conditions. | Nothing ever failed. |
| Did you migrate Workflow Rules or Process Builder to Flow? How did you test it? | A count, the migration approach, and a surprise: order of execution, duplicate automation running twice. | Still builds new Workflow Rules. |
| How did you decide between a Flow and asking a developer for Apex? | A reasoned line: volume, complexity, maintainability, and an example where they chose each. | Either never considered code, or sends everything to developers. |
| How many automations fired on your busiest object, and how did you keep track? | An estimate and a method: documentation, a naming convention, consolidating per-object Flows. | No idea what else ran on the object. |
| Have you hit governor limits in automation? What happened? | A specific case, often a data load triggering a Flow on many records, and the fix. | Has not heard of limits, for a large org. |
Security and access: where admin mistakes cost the most
A layout mistake annoys users. An access mistake shows salary, health or customer data to the wrong people. Spend time here for any org holding sensitive data.
- "How was access structured: profiles, permission sets, permission set groups?" Strong: describes the model and a change they made toward it, such as moving access from many profiles to permission sets. Red flag: everyone cloned the System Administrator profile.
- "What was the org-wide default for your most sensitive object, and how did people get access beyond it?" Strong: names the default and the sharing rules, role hierarchy or teams used. Red flag: does not know what the default was.
- "Tell me about an access problem you found or caused." Strong: a specific exposure or lockout, how it was found, and the fix. Red flag: no story, in a large org.
- "How did you handle a leaver's user record and their data?" Strong: a deactivation process, reassigning records, freezing first when needed. Red flag: deletes users or shares logins.
- "Did you set up single sign-on or multi-factor authentication?" Strong: their part and the identity provider. Red flag: shared admin credentials.
Releases, data and the business side
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| How did a change get from idea to production? | A request process, build in a sandbox, testing with users, deployment by change set, DevOps Center or a release tool, and a release note. | Built in production during the day. |
| How did you prepare for Salesforce's seasonal releases? | Read release notes, tested in a preview sandbox, told users what changed. | Found out about changes from user complaints. |
| Tell me about the biggest data load or cleanup you did. | Record count, the tool (Data Loader, Data Import Wizard, a third-party tool), how they backed up first, and deduplication rules. | Loaded straight into production with no backup or test load. |
| Which report or dashboard did leadership actually use, and what did it change? | A named dashboard, who looked at it, and a decision it drove. | Built many reports; cannot name one that was used. |
| Tell me about a request you pushed back on. | A request that would have added clutter or risk, the alternative they offered, and the outcome. | Builds every field anyone asks for. |
| How did you train users on a change? | Short sessions, in-app guidance, release notes, a feedback loop. | "They figured it out." |
Certifications: names, maintenance and verification
Salesforce certifications are common requests in job descriptions and near-universal on candidate profiles. Three facts help on a screen, as of September 2026:
- The core credential is the Salesforce Certified Platform Administrator. Salesforce's exam guide says candidates should have six or more months of experience as an administrator. It is a knowledge exam; passing it early in a career is normal.
- Certifications need yearly maintenance. Certified professionals complete release maintenance modules on Trailhead once a year to keep their certifications current. A lapsed certification tells you the candidate has stepped away from the platform or stopped maintaining it.
- Verification is public. Salesforce's credential verification page lets you search a person's certifications. Check the name matches and the status is current before you put a certification in a submittal.
Badges, superbadges and Trailhead ranks show study effort. They are fine signals for entry-level and career-change candidates. For experienced admins, the org stories above count for more than the badge count. Treat a long list of certifications with no production story as a reason to ask more questions, not as proof of seniority.
How Salesforce profiles overstate the work
| Pattern | What it looks like | How to check on the call |
|---|---|---|
| Every cloud | Sales, Service, Marketing, Experience, CPQ, Field Service | "Which one did you configure every week?" |
| Certification stack as experience | Many certifications within one year, little work history | Ask for one production change per certification the client cares about. |
| Partner work as ownership | "Implemented Service Cloud" when a consulting partner did the build | "What did the partner build, and what did you own after go-live?" |
| Reports as administration | A sales operations analyst who builds dashboards, titled admin | "Did you have System Administrator access, and what did you change with it?" |
| "Automated processes" | A few field updates | "Walk me through the steps of your most complex Flow." |
| Integration claims | "Integrated Salesforce with the ERP" | "Who built the integration, and what did you do when it failed?" |
Logistics, knockout checklist and scorecard
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| You would be the only admin for 600 users. How have you handled requests at that ratio? | A request intake and prioritization method they have used. | Has always had a team to share requests with. |
| Deployments happen after hours once a month. Does that work? | A clear yes or a limit. | Surprised by any release work outside hours. |
| What salary or rate do you need, and on what basis? | A number and the basis. See salary expectation questions. | Only a salary-site figure. |
| Are you legally authorized to work in the US, and will you now or in the future need visa sponsorship? | A direct answer to both. | None. Ask every candidate the same two questions. |
Knock out, or flag to the client before submitting, if:
- The role is sole admin for a large org and the candidate has never had System Administrator access.
- The client's key cloud is a must-have and the candidate has never configured it.
- The candidate cannot describe a Flow they built step by step.
- A required certification is not current on Salesforce's verification page.
| Area | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Org scope | Small, single cloud, supported by others | Mid-size, some configuration | Large or multi-cloud, owned areas | Complex org, shaped the data model |
| Automation | Field updates only | Simple Flows | Complex Flows with fault handling | Designed automation strategy and migrations |
| Security and data | Cloned profiles | Basic permission sets | Sharing model changes, clean data loads | Access redesign and governance |
| Release and stakeholders | Changes in production | Sandbox testing | Release process and user training | Owns roadmap and pushes back with alternatives |
| Logistics fit | Deal-breaker | Two open questions | One open question | All aligned |
Write the evidence beside each score in the candidate's words. "Migrated 60 Workflow Rules to Flow; 'two ran twice on Opportunity and we caught it in UAT'" tells a CRM manager more than "Flow expert." Interview Signal attaches quotes like that to each score from the call.
Questions people ask
Is the Salesforce Administrator certification enough to hire someone?
It shows the candidate studied the platform's standard features, and Salesforce's exam guide suggests around six months of admin experience before taking it. It does not show they have run a complex org. Ask about the org's size, the automation they built and a change that went wrong.
What is the difference between a Salesforce administrator and a Salesforce developer?
An administrator configures the platform with clicks: objects, fields, page layouts, permissions, reports and Flow automation. A developer writes code such as Apex and Lightning Web Components. Many admins do some of both, so ask what share of their changes needed code and who wrote it.
How do I verify a candidate's Salesforce certifications?
Salesforce runs a public credential verification page on Trailhead where you can look up a person's certifications. Certifications also need a maintenance module each year, so check the status is current, not only that it was earned.
Should a Salesforce admin know Workflow Rules and Process Builder?
Only enough to migrate away from them. Salesforce ended support for both at the end of 2025 and recommends Flow. An admin who still builds new automation in them is behind; one who has migrated them is a plus.