15 Salesforce Administrator Interview Questions (2026)

1. What is the difference between a Profile and a Permission Set?

Security-model fundamentals come up in nearly every Salesforce admin interview because misconfiguration here creates real business risk. Interviewers want to know you understand that profiles define baseline access and permission sets extend it — and that modern best practice leans heavily on permission sets. A weak answer treats them as interchangeable.

A profile is assigned one-per-user and controls baseline object, field, and system permissions, while permission sets layer additional access on top without modifying the profile. Salesforce's current guidance is to use minimum-access profiles and grant everything else through permission sets and permission set groups, which scales better as your org grows. I've been migrating older orgs away from profile-heavy models because it dramatically simplifies user provisioning.

2. When would you use Flow Builder versus an Apex trigger?

Admins operate on the declarative side, but you need to know the boundaries. Interviewers check whether you understand Flow's limits and when to escalate to a developer. Answering "always use Flow" or "always use Apex" is a red flag either way.

Flow Builder handles the vast majority of automation I build — record-triggered flows for CRUD logic, screen flows for guided user experiences, and scheduled flows for nightly jobs. I'd involve a developer when I need complex recursion handling, callouts with custom retry logic, or logic that needs to run before validation rules fire in a way Flow can't express cleanly. I also avoid Flow for extremely high-volume mass updates where Apex batch is more efficient.

3. Process Builder is retired — how do you handle legacy Process Builder automations?

This question tests whether you're current with the platform. Process Builder was officially retired, and many orgs still have legacy PBs running. Salesforce provides migration tools, and a good admin knows the pragmatic path.

I use the Migrate to Flow tool as a starting point but I always review the output rather than accepting it blindly — it often produces flows that work but aren't optimally structured. My approach is to inventory all active Process Builders, prioritise the business-critical ones, and migrate object by object so I can consolidate multiple processes into a single record-triggered flow per object. That consolidation is where the real performance and maintainability gains come from.

4. Walk me through how you would set up a new sharing model for a sales org.

Sharing architecture is one of the hardest things for an admin to get right, and interviewers want to see you think in layers. A good answer covers OWDs, role hierarchy, sharing rules, and manual sharing — in that order.

I'd start by setting organisation-wide defaults as restrictively as the business allows, usually Private for Opportunities and Cases. Then I'd build the role hierarchy to grant upward visibility for managers. Sharing rules handle the exceptions — for example, sharing all UK opportunities with the UK sales team via criteria-based rules. Manual sharing and Apex sharing are last resorts I avoid unless there's no declarative option.

5. How do you approach validation rules without blocking legitimate user workflows?

Validation rules are powerful but easy to over-engineer into a user-experience disaster. Interviewers are checking whether you balance data quality with user empathy. Listen for candidates who mention testing with real users.

I write validation rules to prevent genuine data problems, not to enforce every possible business preference. Before deploying, I test with a handful of power users from the affected team to find edge cases where the rule blocks legitimate work. I also make error messages specific and actionable — "Close Date cannot be in the past" rather than "Invalid data." I audit existing validation rules quarterly and retire any that haven't fired meaningfully.

6. How do you plan and execute a data import of 100,000 records?

Large data imports are an admin staple and a common source of disasters. Interviewers want a methodical answer covering tooling, staging, validation, and rollback. Hearing "I'd just use Data Loader" without mentioning sandbox testing is a warning sign.

I start in a full or partial sandbox, never in production. I use Data Loader or Data Import Wizard depending on object support, and I always do a dry-run import of the first 100 rows to catch mapping and picklist issues. I load in batches of 10,000 with hard-delete disabled so I have a rollback path. Before production load I disable triggers and validation rules that would interfere, then re-enable and run a reconciliation report afterwards.

7. Explain the difference between a Report Type and a Report Folder.

Reporting fundamentals come up because they trip up self-taught admins. A solid answer shows you understand the metadata distinction and how custom report types unlock reporting on related objects.

A report type defines which objects and fields are available to build a report on — it's the schema layer. Custom report types are essential when you need to report across related objects that aren't available out of the box, like Accounts with Opportunities with Products. Report folders are just organisational containers that control who can view or manage a set of reports. Confusing them is a common tell for someone new to the platform.

8. How do you manage deployments between sandbox and production?

Release management separates senior admins from juniors. Interviewers want to hear about change sets, DevOps Center, or Git-based workflows, and an understanding of the tradeoffs.

For smaller orgs I still use change sets when the team is small and changes are infrequent. For anything more active I've moved to DevOps Center because it supports source-driven development and Git-based tracking without requiring developers on the team. I always deploy to a UAT sandbox first, run regression tests on critical flows, and schedule production deploys outside business hours with a documented rollback plan.

9. What metrics do you use to measure data quality in an org?

Data quality is the quiet killer of Salesforce adoption, and good admins track it actively. Interviewers are looking for specific measurable indicators rather than vague "keeping data clean" answers.

I track completeness on critical fields like Account Industry and Opportunity Stage, duplicate rate using Matching Rules, and stale-record rate for Contacts and Leads. I build a Data Quality dashboard that managers see weekly, broken down by owner so there's accountability. I also monitor the failure rate of integrations and validation rules — a sudden spike usually means an upstream system changed its payload.

10. How do you handle a business request that would require significant customisation?

Scope and stakeholder management is a huge part of the admin role. Interviewers want to see you push back constructively and steer toward standard functionality when possible.

I always ask "what's the underlying business outcome?" before scoping the technical solution. Nine times out of ten there's a declarative way to solve it that the stakeholder hadn't considered. If custom development is genuinely required, I document the cost in admin time, ongoing maintenance, and technical debt, then present the tradeoff to the sponsor. I'd rather lose the argument honestly than ship a fragile custom solution I'll regret maintaining.

11. What is your experience with Lightning Experience migration?

Many orgs still have pockets of Classic or have half-migrated. Interviewers want to know you can handle the transition pragmatically and know the common gotchas.

I've led two full Classic-to-Lightning migrations. The hardest parts are usually JavaScript buttons that don't work in Lightning and custom VisualForce pages that need rebuilding as Lightning components. I use the Lightning Readiness Report to inventory the work, prioritise high-usage screens, and pilot with a friendly team before org-wide rollout. I also budget time for user enablement because the UI change is the real adoption risk.

12. How do you stay current with each Salesforce release?

The platform ships three major releases a year, and admins need a system for staying on top of them. Interviewers want evidence you engage proactively rather than react to broken flows.

I read the release notes during the preview window and build a shortlist of features relevant to our org. I spin up a pre-release sandbox to test anything that touches critical automations — retirement announcements especially. I share a five-minute release summary with our power users before every deployment so they know what's changing. Trailhead release modules and the Admin Evangelists' YouTube channel are my two most-used external sources.

13. Tell me about a time you had to push back on a stakeholder request.

Behavioural questions in admin interviews almost always touch on stakeholder politics. Interviewers want evidence you can disagree professionally and bring data to the conversation.

A sales director wanted a required custom field added to every Opportunity stage, which would have broken inline editing and slowed down his own team. Instead of just saying no, I built a quick sandbox demo showing the user-experience impact and pulled usage data showing only 12% of reps were completing the optional version. We ended up solving his underlying reporting need with a validation rule at Closed-Won stage only, which gave him the data without the friction.

14. Which Salesforce certifications do you hold, and what are you working toward next?

Certifications aren't everything, but they signal commitment to the craft. Interviewers are checking both current knowledge and growth trajectory.

I hold the Administrator (ADM-201) and Advanced Administrator certifications, plus Platform App Builder. I'm currently studying for the Business Analyst certification because so much of my work involves requirements-gathering and process design. Longer term I'd like to pursue the Application Architect path because understanding the architectural tradeoffs makes me a better admin even when I'm not making those decisions myself.

15. Why are you interested in working a four-day week?

Companies offering reduced schedules want admins who can prioritise and work asynchronously rather than be always-on. This question tests whether you've thought about how you'd operate with less calendar time.

A lot of admin work is reactive — user requests, broken flows, data fixes — so I've learned to batch those into defined windows rather than context-switching all day. A four-day week would force me to lean harder into self-service documentation and proactive monitoring so the team doesn't depend on me being online constantly. I think that discipline makes for a better admin function overall, not just a happier one.