Top Salesforce Admin Interview Questions & Answers (2026)
17 questions Salesforce Administrator interviewers actually ask, with the strong answer, the weak one, and the follow-up that comes next.
- Salesforce AdminRole
- $70K-$115KTypical US pay
- 3-4 roundsInterview loop
- Often requestedCert in hiring
- OftenHands-on test
Table of Contents
Salesforce admins are hired by companies of every size that run sales, service or operations on the platform, from a 40-seat startup with one accidental admin to enterprises with a whole Center of Excellence. Most 2026 interviews are run by a sales or revenue operations leader plus an existing admin or architect, and they lean heavily on scenarios: a user who can't see a record, a flow that misfires, a stakeholder who wants everything changed by Friday.
The Platform Administrator credential is the most common filter on admin postings, and since the December 2025 refresh it also covers Agentforce basics. It shows you know where the settings live. The interview checks whether you can reason through security, automation and data problems out loud, protect production, and say no to a VP politely.
What the Salesforce Administrator interview loop looks like
Most Salesforce Administrator hiring runs 5 rounds. Each one is testing something different, so prepare for each separately.
The 17 questions, with answers
Each card shows the question as it is usually asked, what the interviewer is really checking, a strong answer, the weak answer they hear most often, and the follow-up that comes next. Say the strong answers in your own words — a memorised script sounds memorised.
- Basic · 4
- Core · 5
- Advanced · 3
- Scenario · 3
- Behavioural · 2
What's the difference between a profile and a permission set, and how do you decide where a new permission goes?
What they are testing: Whether you understand the current permission-set-led model, not the 2015 profile-for-everything approach
Every user has exactly one profile, but can have many permission sets, and permission sets only ever add access. I group them into permission set groups by job function, and use a muting permission set if one group grants slightly too much. Salesforce planned to remove permissions from profiles in Spring '26, then said in mid-2026 it won't enforce that date, but it still recommends a permission-set-led model. So I keep profiles minimal, things like login hours, IP ranges and page layout assignment, and put object, field and system permissions in permission sets. That makes access easier to audit and to grant to one person without cloning a profile.
Explain org-wide defaults, the role hierarchy and sharing rules. Which direction does each one move access?
What they are testing: That you know OWD is the floor and everything else only opens access up
Org-wide defaults set the baseline record access for each object, so I set them to the most restrictive level any user needs, often Private for accounts and opportunities. The role hierarchy then opens access upward, so a manager sees what their team owns. Sharing rules open access sideways, by owner or by criteria, to groups or roles that sit outside that line. On top of that you have teams and manual sharing. None of these can take access away below the default. Also, sharing decides which records you see, while object and field permissions decide what you can do with them, and you need both.
A user says a field is missing on a record they're looking at. How do you troubleshoot it?
What they are testing: A methodical order of checks rather than guessing at random settings
First I'd confirm which record, which record type and which app they're in, ideally by logging in as them if that's enabled. Then I go layer by layer. Field-level security: does their profile or any permission set give read access to the field? Page layout: is the field on the layout assigned to their profile and record type? Lightning record page: is it a Dynamic Forms field with a visibility filter hiding it? I also check the field accessibility view in Setup, which shows the combined result per profile and record type. Once I find the cause I fix it through a permission set or layout change, not by editing their profile on the spot.
Write me a validation rule, out loud, that forces a loss reason when an opportunity is set to Closed Lost.
What they are testing: Formula logic, the 'TRUE means error' rule, and picklist handling
A validation rule blocks the save when its formula evaluates to true, so I describe the bad state. Assuming Loss Reason is a picklist, it would be AND(ISPICKVAL(StageName, "Closed Lost"), ISBLANK(TEXT(Loss_Reason__c))). I use ISPICKVAL and TEXT because you can't compare picklists directly. I'd put the error message on the Loss Reason field itself so the user sees it where they need to act, and word it as an instruction, like 'Select a loss reason before closing this opportunity as lost.' If an integration also writes stages, I'd add a custom permission check so the integration user can bypass it.
Workflow Rules and Process Builder are out of support. Which Flow types do you use, and when?
What they are testing: Current automation knowledge and the before-save versus after-save distinction
Salesforce ended support for Workflow Rules and Process Builder at the end of 2025, so new automation goes in Flow, and the Migrate to Flow tool helps convert old ones. For record changes I use record-triggered flows. If I'm only updating fields on the same record, I use a before-save flow, the fast field update option, because it doesn't need another database write. If I need to create related records, send emails or call actions, it's an after-save flow, sometimes with a scheduled path for time-based work. Screen flows handle guided user processes, schedule-triggered flows handle nightly batch jobs, and autolaunched flows are called from other flows, Apex or agent actions.
How do you choose between the Data Import Wizard and Data Loader, and how do you avoid duplicates on a big import?
What they are testing: Tool limits, upsert with external IDs, and import hygiene
The Data Import Wizard is browser-based, handles up to 50,000 records, covers common objects like accounts, contacts, leads and custom objects, and has simple matching built in. Data Loader is a client app that handles up to five million records, works on every object, and supports upsert, delete and export, plus command-line runs. For duplicates I make sure there's an external ID field from the source system and upsert on it, so reruns update instead of creating copies. I also check the matching and duplicate rules, clean the file first, take an export as a backup, and run a small test batch in a sandbox before production.
Walk me through the sandbox types and how you'd move a change from sandbox to production.
What they are testing: Release discipline and knowing what each sandbox is for
Developer and Developer Pro sandboxes copy metadata only and can be refreshed daily, so they're for building. Partial Copy adds a sample of data defined by a sandbox template and refreshes every five days, which suits testing. Full copies everything and refreshes every 29 days, so it's for UAT, training and performance testing. To deploy with change sets, I set up a deployment connection, build an outbound change set with the components and their dependencies, upload it, then validate the inbound change set in production before deploying. Change sets can't delete components, so I document manual steps. Many teams are moving to DevOps Center or source-driven deployments, and I'm comfortable with either.
A sales manager says her dashboard shows totals her reps can't see. How is that possible?
What they are testing: Dashboard running user and how reports respect sharing
Reports always run with the sharing of the person running them, but a dashboard runs as a specific running user. If the dashboard's running user is the manager or an admin, everyone who opens it sees totals based on that user's access, which can be more than reps see in the underlying report. The fix depends on intent. If reps should only see their own numbers, I'd make it a dynamic dashboard that runs as the logged-in user, keeping in mind dynamic dashboards have a per-org limit. If the totals are fine to share, I'd document that and lock down the folder so only the right audience can open it.
When would you create a record type instead of just adding another page layout?
What they are testing: Whether you avoid record-type sprawl and understand business processes
I create a record type when the business process genuinely differs, meaning different picklist values, different sales or support processes, or different stages, for example renewals versus new business. A page layout alone is enough when the fields shown differ but the process and picklists are the same. With Dynamic Forms I can often show or hide fields by criteria without either one. Record types are expensive to maintain, since every report, automation and validation rule has to account for them, so I ask what will actually behave differently before adding one. Assignment is per profile, so I'd also plan which users get access to each.
Design sharing for a private Account model where regional teams need access to each other's accounts only when they work a joint deal.
What they are testing: Combining OWD, hierarchy, teams and rules without over-granting
I'd keep Account and Opportunity on Private and build the role hierarchy by region so regional managers see their own teams. For the joint deals, a blanket sharing rule between regions would over-share, so I'd use opportunity teams and account teams: when a rep from another region joins a deal, they're added to the team with read or edit access on that record only. If joint deals follow a clear criterion, like a Partner Region field, a criteria-based sharing rule to that region's group also works. For larger orgs with territory logic, Enterprise Territory Management is the cleaner model. I'd avoid View All on the object entirely.
You inherit an org with several flows on one object that sometimes loop or hit limits. How do you clean it up?
What they are testing: Governor limits, flow ordering and entry condition design
First I'd map every automation on the object, including old Process Builders and triggers, using Flow Trigger Explorer to see order and type. Common causes are flows updating the same record in after-save, which re-fires automation, and DML or queries inside loops, which hits limits like 100 SOQL queries and 150 DML statements per synchronous transaction. My fixes: move same-record updates to before-save flows, tighten entry conditions so flows run only when relevant fields change, collect records in a collection and update once outside the loop, and set explicit trigger order. I'd add fault paths that notify the admin team, then test in a full sandbox with realistic data volumes.
Your company wants to pilot an Agentforce agent for the service team. As the admin, what do you set up and what worries you?
What they are testing: Practical, security-first thinking about AI features the exam now covers
I'd start with one narrow use case, like order status or simple case triage, and build in a sandbox. In Agentforce you define topics and the actions the agent can take, and those actions are often flows, Apex or prompt templates I already understand. My main worry is access: the agent acts with a defined user's permissions, so I'd give it a tightly scoped permission set, not admin rights. I'd check the data it grounds on, such as Knowledge articles, is current, test many real conversations before launch, keep a clean handoff to a human, and review conversation logs after go-live.
A VP asks you to give the whole sales team Modify All Data so they stop complaining about access. What do you say?
What they are testing: Least privilege, stakeholder handling and finding the real problem
I'd thank them and ask what the reps are actually blocked on, because Modify All Data lets anyone edit or delete every record in the org, which is a real security and audit risk. Usually the complaint is specific: they can't edit accounts owned by someone else, or can't see a related object. I'd collect three or four concrete examples, find which layer is blocking each one, and fix it narrowly with a sharing rule, team access or a permission set. Then I'd go back to the VP with what I changed, the time it took, and why we avoided the blanket permission. Most leaders accept that when they see the problem fixed.
Someone mass-updated 3,000 account records with the wrong owner on Friday. It's Monday. How do you recover?
What they are testing: Calm incident handling and knowing where historical data lives
First I'd stop it getting worse: find out who did it and how, through the setup audit trail, login history or the job in Data Loader, and pause any automation reacting to the change. Then I'd find the original values. If field history tracking is on for Owner, I can report on account history and build a correction file. Otherwise I'd use the most recent backup, whether that's a weekly data export, a backup tool or a recent full sandbox. I'd restore with Data Loader upsert on the record ID, test a small batch first, then tell affected managers. Afterwards I'd look at who has mass-edit rights and propose a backup schedule if we didn't have one.
A director wants a new field required on Case by end of day. Two integrations write to Case. How do you handle it?
What they are testing: Understanding of how required settings affect integrations and release safety
I'd first ask why it's needed and when the data is actually known, because there are three ways to make a field required and they behave differently. Required on the page layout only affects users in the UI. Universally required at the field level, or a validation rule, also applies to the API, so both integrations would start failing if they don't send the value. I'd check with the integration owners, then likely use a validation rule that only applies to human users, bypassed by a custom permission for integration users. I'd test in a sandbox, give users a heads-up, and deploy that day if the test passes, rather than rushing it straight into production.
Tell me about a time you pushed back on a request from a stakeholder.
What they are testing: Whether you can say no with evidence and still keep the relationship
Template to fill with your own story. Situation: a sales leader asked for a new custom object to track something an existing object already handled. Task: I owned the backlog and wanted to avoid duplicate data. Action: I asked what decision they wanted to make with the data, showed a quick prototype using the existing object plus two fields and a report, and explained the reporting and maintenance cost of a separate object. Result: they accepted the simpler version, it shipped in a week instead of a month, and it stayed one source of truth. Keep the conflict polite, show what you offered instead, and quantify the outcome.
Describe a time you had to learn a Salesforce feature quickly to solve a real problem.
What they are testing: Self-directed learning and how you validate before shipping
Template to fill with your own story. Situation: our team needed time-based reminders after Process Builder went out of support. Task: I had two weeks to rebuild them in Flow. Action: I worked through the relevant Trailhead modules, built the first flow with a scheduled path in a developer sandbox, compared its behaviour against the old process using test records, and wrote a short page for the team on how it worked. Result: we migrated all reminders with no missed notifications, and I later reused the pattern for three other processes. Name the resources you used and how you proved it worked.
Get the theory airtight before the interview
Interviewers build follow-ups on the fundamentals. The Salesforce Admin app has exam-style Salesforce Admin questions with an explanation for every option, so the basics stay automatic when the questions get harder.
App StoreGoogle PlayFree Salesforce Admin practice testThe practical task
Expect some version of this. Companies vary the details, not the shape.
Our SDRs qualify inbound leads by budget, timeline and fit. Add the fields we need, stop anyone converting a lead that isn't qualified, assign qualified leads to the right regional queue automatically, and give the SDR manager a dashboard of qualified leads by source this month. SDRs must not see each other's unconverted leads. Walk us through what you built and why.
- Confirm assumptions first: which regions, who owns leads, what counts as qualified, and whether integrations create leads.
- Add picklist fields with clear help text, and set Lead OWD to Private with a permission set for SDR access.
- Write a validation rule that blocks conversion unless qualification fields are set, with an error on the right field.
- Use a record-triggered flow or assignment rule to route qualified leads to regional queues, with clear entry conditions.
- Build a summary report grouped by lead source and a dashboard component, and explain the dashboard running user choice.
- Test as an SDR user, then list what you'd do before production: sandbox testing, user training, change notes.
Hire vs no-hire:Hires ask clarifying questions, test as a non-admin user, explain why they picked Flow versus assignment rules, and mention security. No-hires build only as admin and never check what an SDR actually sees.
Questions to ask them
"Do you have any questions for us?" is still being scored. Four that land well for a Salesforce Administrator role:
Mistakes that sink candidates
What the Salesforce Certified Platform Administrator does and does not prove
What the Salesforce Certified Platform Administrator gets you
The Platform Administrator credential is the most commonly requested certification on Salesforce admin postings, and many recruiters and partner consultancies screen for it directly. For career changers without on-the-job experience it is often the only way past the first filter. It also signals you know current terminology, since the December 2025 refresh added Agentforce and shifted weight toward data and analytics.
What it does not prove
The exam is multiple choice, so it doesn't prove you can troubleshoot a real access problem live, design sharing for a messy org, untangle overlapping flows, or manage stakeholders who all want something different. Interviews probe exactly those. They also test release discipline, data cleanup judgement and how you explain trade-offs to non-technical leaders, none of which a passing score shows.
Pay:Range based on Indeed's US average base pay for Salesforce Administrator ($91,420, range about $63K-$132K, updated October 2026) and BLS May 2025 data for computer systems analysts ($105,850 median). Org size, extra clouds, Flow depth and Platform App Builder or Advanced Admin credentials push pay up.
Still sitting the Salesforce Admin?
Pass it first time and walk into the interview with the credential on your CV. The Salesforce Admin app has exam-style Salesforce Admin questions with an explanation for every option.
App StoreGoogle PlayFree Salesforce Admin practice testFAQ
Can I get a Salesforce admin job with only the certification and no experience?
It's possible but harder than it was a few years ago, because many postings now ask for one to three years of hands-on work. Candidates who succeed without a job title usually show proof instead: a developer org with real builds, volunteer admin work for a nonprofit, or Trailblazer community projects. Expect to start in a junior admin, support or business analyst role and grow from there.
Will they ask me to build something live in a Salesforce org?
Often, yes, especially at partners and mid-size companies. It's usually a small requirement in a developer org: a few fields, a validation rule, a flow and a report, done in under an hour while you narrate. Some send a take-home instead. Practise building common requirements quickly in your own free developer org and get comfortable explaining choices while you click.
How technical is a Salesforce admin interview in 2026?
More than the job title suggests. You won't be asked to write Apex, but you will be expected to explain the security model, design flows correctly, write formula logic for validation rules, and understand deployments and governor limits at a basic level. Interviewers also increasingly ask how you'd configure and govern AI features such as Agentforce agents.
How should I prepare for scenario questions?
Practise a consistent troubleshooting order: who is the user, what exactly fails, then check object permissions, field-level security, record sharing, layouts and automation in turn. Use real stories where you can, with the business outcome. For design scenarios, state assumptions first, give the simplest secure option, then mention what you'd do at larger scale.
Do I need the Platform App Builder or Advanced Administrator certification too?
Not to get an entry or mid-level admin role, but they help. Platform App Builder signals deeper data model and automation design, and is common on partner job ads. Advanced Administrator (now Platform Administrator II) suits admins with a few years of experience. Experience you can explain in detail still outweighs a second certificate in most interviews.
Sources
Figures on this page come from Salesforce and the other primary sources below:
- Salesforce Certified Platform Administrator credential - Trailhead
- Salesforce Administrator salaries in the United States - Indeed
- Computer Systems Analysts - BLS Occupational Outlook Handbook
- Salesforce Platform Admin exam updated for 2026 - Salesforce Ben
- What the community thinks about Salesforce's permissions U-turn - Salesforce Ben
- Salesforce announces end of support for Workflow Rules and Process Builder - Salesforce Ben
Checked November 4, 2026. Fees, outlines and eligibility rules change — confirm with Salesforce before you book.