Salesforce Admin Interview Questions
50 verified Q&As · Security · Automation · Data Model · Reports · Data Management
These Salesforce Admin interview questions are organized the way a real screen runs: by competency, from quick definitions to applied scenarios. Each one carries a short answer key so a candidate can self-check and an interviewer can scan what a strong response looks like without re-deriving it on the spot.
The set is calibrated to the level most admin roles actually hire at — predominantly Junior and Mid, with a few Senior trade-off questions and two behavioral prompts at the end. Every technical answer key was checked against current official Salesforce behavior, including the Summer ’26 release and the recent changes to automation tooling and the profile security model.
How to use this list
Candidates: cover the answer key, attempt a verbal answer in 1–3 minutes, then compare. Interviewers: the tags show the competency and level, and the bullets are the points a strong answer should hit — not a script to read back.
01 — Security
Security & Access Model
This is the highest-yield area in almost every Salesforce Admin interview. The questions below probe whether you understand the layered security model rather than just where the buttons live.
Q1What is the difference between a profile and a role?
A profile defines what a user is allowed to do — which objects and fields they can access and which system-level actions they can take. A role sits in the role hierarchy and controls which records a user can see. Every user must have a profile, but a role is optional.
Strong answer hits
- Profile controls what a user can do — object, field, and system permissions.
- Role controls what records a user can see, via the role hierarchy on top of OWD.
- Every user must have one profile; a role is optional.
Q2Walk me through the order of the data security layers in Salesforce.
Salesforce security is layered, so I walk it top to bottom. It starts with object-level security through profiles and permission sets, then record access through org-wide defaults, the role hierarchy, sharing rules, manual sharing, and teams. After that comes field-level security, and finally the page layout and UI.
Strong answer hits
- Object-level security (OLS) first — profiles and permission sets.
- Then record access: OWD, role hierarchy, sharing rules, manual sharing, teams.
- Then field-level security (FLS), then page layout / UI.
Follow-up: Where does “Controlled by Parent” fit in?
Q3What do org-wide defaults (OWD) control, and what are the options?
Org-wide defaults set the baseline level of record access for each object — the most restrictive starting point before anything opens it up. The options are Private, Public Read Only, Public Read/Write, and Controlled by Parent. Everything else, like sharing rules or the hierarchy, can only widen access, never tighten it below the OWD.
Strong answer hits
- OWD sets the baseline (most restrictive) record access per object.
- Options: Private, Public Read Only, Public Read/Write, Controlled by Parent.
- Other mechanisms only open access up — never tighten below OWD.
Q4Give a regional manager read access to only their region’s accounts, without opening accounts to everyone. How?
I’d set the Account org-wide default to Private so records aren’t visible by default. Then I’d create a sharing rule — owner-based or criteria-based — that shares the region’s accounts with that manager, usually through a public group or role, at Read Only. That gives them visibility into their region without exposing every account in the org.
Strong answer hits
- Set the Account OWD to Private.
- Use a criteria-based or owner-based sharing rule scoped to the region.
- Share to a public group or role; grant Read Only access.
Follow-up: What if regions overlap and a manager covers two?
Q5When would you use the role hierarchy versus a sharing rule to grant access?
The role hierarchy automatically gives managers access to records owned by people below them, so it follows the management chain. Sharing rules are for lateral access — granting a role or group records they wouldn’t otherwise see. Both only extend access; neither can restrict below the OWD.
Strong answer hits
- Role hierarchy grants managers access to their subordinates’ records.
- Sharing rules grant lateral access to roles, groups, or by criteria.
- Both extend access; neither can restrict below OWD.
Q6A user can see a record they shouldn’t. How do you troubleshoot the access?
I’d work through the layers systematically — check the OWD, the role hierarchy, any sharing rules, manual shares, and team membership. The record’s Sharing button shows exactly why someone has access. I’d also look at ownership, implicit sharing from a parent record, and whether a “View All” permission is overriding sharing.
Strong answer hits
- Check OWD, role hierarchy, sharing rules, manual shares, and team membership.
- Use the record’s Sharing button / sharing hierarchy to trace the grant.
- Consider ownership, implicit sharing from a parent, and “View All” permissions.
Q7Why would you use a permission set instead of editing a profile?
A profile is the baseline and each user gets exactly one, so editing profiles for small differences quickly leads to profile sprawl. Permission sets let me grant extra access on top without cloning profiles. Salesforce’s recommended approach now is a permission-set-led model, often bundled into permission set groups by job function.
Strong answer hits
- Profiles set a baseline (one per user); permission sets add access on top.
- Avoids cloning near-duplicate profiles for small differences.
- Salesforce recommends a permission-set-led model with permission set groups.
Q8What is a permission set group, and what is a muting permission set?
A permission set group bundles several permission sets so you can assign access by job function in one go. A muting permission set works the opposite way — it removes or mutes specific permissions inside that group. So a user’s net access is the combined grants minus whatever’s muted.
Strong answer hits
- A permission set group bundles permission sets, assigned by job function.
- A muting permission set removes specific permissions within that group.
- Net access = combined grants minus the muted permissions.
Q9Distinguish object “View All / Modify All” from the “View All Data / Modify All Data” permissions.
View All and Modify All are object-specific — they let a user see or edit all records of that one object, ignoring sharing. View All Data and Modify All Data are org-wide super-permissions across every object. For least privilege, I reach for the per-object version rather than the org-wide one whenever possible.
Strong answer hits
- View All / Modify All apply to a single object and ignore sharing for it.
- View All Data / Modify All Data are org-wide super-permissions.
- Least-privilege: prefer the per-object version over the org-wide one.
Watch out — common trap
Candidates often say profiles “restrict” record access. Profiles and permission sets govern object and field access (OLS/FLS); record visibility is governed by OWD, the role hierarchy, and sharing. Mixing these two axes is the most common interview stumble.
02 — Users
User Management & Permissions
These Salesforce Admin interview questions cover the day-to-day of running an org: user lifecycle, access grants, and the current direction of the profile model.
Q10What is the difference between deactivating and freezing a user?
You can’t delete a user in Salesforce — you either deactivate or freeze them. Deactivating frees up the license and removes the user from the role hierarchy. Freezing just blocks their login but keeps the license, which is useful when someone leaves and you need time to reassign their records before deactivating.
Strong answer hits
- You cannot delete users — only deactivate or freeze.
- Deactivate frees the license and removes the user from the hierarchy.
- Freeze blocks login but keeps the license while you reassign records.
Q11Given Salesforce’s direction on permission sets, what is the current best-practice role of the profile?
Even with the move toward permission sets, every user still needs a profile, and the planned retirement of permissions on profiles was postponed. So today I treat the profile as the baseline — default apps, page layout assignment, login hours and IP ranges — and put the actual access into permission sets and permission set groups.
Strong answer hits
- Profile = baseline: default apps, page layout assignment, login hours/IP.
- Grant access through permission sets and permission set groups.
- The permissions-on-profiles retirement was postponed — profiles remain required.
Q12What is a public group, and where is it used?
A public group is a reusable collection of users, roles, roles-and-subordinates, or even other groups. I use them anywhere I’d otherwise list people individually — sharing rules, folder access, and list view sharing. It keeps grants much easier to maintain as people change.
Strong answer hits
- A collection of users, roles, roles-and-subordinates, or other groups.
- Used in sharing rules, folder access, and list view sharing.
- Simplifies grants by referencing a group instead of individuals.
Q13How would you grant a user elevated access for a short-term project, then remove it cleanly?
I’d avoid touching the profile and instead assign a dedicated permission set for the project. If the platform supports it, I’d set an expiration date on that assignment so it self-removes. Either way, when the project ends I just remove the assignment and the extra access is cleanly revoked.
Strong answer hits
- Assign a dedicated permission set rather than editing the profile.
- Use a permission set expiration / time-based assignment if available.
- Removing the assignment cleanly revokes the extra access.
Q14What is the difference between a permission set and a permission set license?
A permission set is the thing that actually grants settings and access to a user. A permission set license enables a whole feature set those permissions draw on. The order matters — a user often needs the license assigned before certain permissions in the set can take effect.
Strong answer hits
- A permission set grants settings and access to a user.
- A permission set license enables a feature set those permissions can use.
- The user needs the license before certain permissions can be assigned.
Q15A new hire can log in but can’t see the Opportunities tab. Where do you look?
I’d check three things in order. First, tab visibility on their profile or permission set; second, whether they’re assigned the right Lightning app; and third, object-level read access on Opportunity, because without that the tab won’t show at all.
Strong answer hits
- Tab visibility on the profile or permission set.
- App assignment — is the right Lightning app available to them?
- Object read access (OLS); without it the tab won’t appear.
Q16What is delegated administration?
Delegated administration lets you give certain non-admins limited admin powers over a defined scope — specific roles, permission sets, and custom objects. It’s how you let, say, a team lead manage their own users without handing them full System Administrator access.
Strong answer hits
- Lets non-admins manage a defined subset of users and access.
- Scope: specific roles, permission sets, and custom objects.
- Avoids handing out full “Manage Users” / System Administrator rights.
03 — Data Model
Data Model & Relationships
Relationship types and their downstream effects (sharing, roll-ups, cascade delete) are a favorite area because they expose whether a candidate understands consequences, not just definitions.
Q17Compare a master-detail relationship with a lookup relationship.
A master-detail relationship is tightly coupled — the child inherits the parent’s owner and sharing, the parent is required, and deleting the parent cascades to the children. A lookup is loosely coupled — optional, with independent ownership and no cascade delete by default. One key consequence is that roll-up summary fields only work on master-detail.
Strong answer hits
- Master-detail: child inherits owner/sharing, cascade delete, required parent.
- Lookup: loosely coupled, optional, independent ownership, no cascade by default.
- Roll-up summary fields require master-detail.
Q18What is a roll-up summary field, and what are its constraints?
A roll-up summary field aggregates child records up to the parent — a count, sum, min, or max. The catch is that it generally requires a master-detail relationship, with only a few standard exceptions like Account to Opportunity. You can’t add one on a standard custom lookup, which trips a lot of people up.
Strong answer hits
- Aggregates child records (COUNT, SUM, MIN, MAX) onto the parent.
- Available on master-detail (and a few standard relationships, e.g. Account–Opportunity).
- Not available on a standard custom lookup — that’s a common trap.
Q19How do you model a many-to-many relationship in Salesforce?
You model it with a junction object — a custom object that sits in the middle. You give it two master-detail relationships, one to each of the objects you’re linking. Each junction record then represents one pairing between the two sides.
Strong answer hits
- Create a junction object.
- Give it two master-detail relationships, one to each parent.
- Each row links one record from each side.
Q20What is a record type used for?
A record type lets a single object behave differently for different users or business processes. It can offer a different subset of picklist values, a different page layout, and a different business process. So one object — say Opportunity — can support two sales motions cleanly.
Strong answer hits
- Offers different picklist value sets per record type.
- Drives different page layouts and business processes.
- Lets one object serve distinct processes for different users.
Q21Two business lines need different Opportunity stages on the same object. How do you configure it?
I’d create a record type for each business line, then define a sales process for each that exposes only the relevant Stage picklist values. I’d assign the record types and matching page layouts through the profile or permission set, so each team sees only their own stages.
Strong answer hits
- Create record types for each business line.
- Define sales processes that subset the Stage picklist values.
- Assign record types and layouts via profile / permission set.
Q22Explain the purpose of a formula field versus a roll-up summary versus a validation rule.
A formula field calculates a read-only value on the same record or pulls one from a related record. A roll-up summary aggregates child records onto a master. A validation rule is about integrity — it checks a condition and blocks the save with an error if the data isn’t right. Three different jobs.
Strong answer hits
- Formula: derived, read-only value on the same or a related record.
- Roll-up summary: aggregate of child records onto a master.
- Validation rule: enforces data integrity by blocking a bad save.
Q23For a junction object with two master-detail relationships, what determines record sharing?
With a junction object, the first master-detail relationship you create becomes the primary parent, and that parent controls the junction record’s sharing and ownership. So the order you build the relationships in actually matters, along with whether you allow reparenting. I’d set the primary deliberately, based on which side should drive access.
Strong answer hits
- The first master-detail relationship created is the “primary” parent.
- The primary parent controls the junction record’s sharing and ownership.
- Reparenting and the primary choice affect access — set deliberately.
04 — Automation
Automation with Flow
Automation answers are where currency matters most. With the legacy tools now out of support, an interviewer is partly checking whether your knowledge is up to date.
Q24What replaced Workflow Rules and Process Builder, and what is their support status now?
Flow Builder is the answer — it’s Salesforce’s modern, recommended automation tool. Workflow Rules and Process Builder both reached end of support on December 31, 2025; existing ones still run, but you can’t create new ones and there are no more bug fixes. For moving the old automation over, Salesforce provides the Migrate to Flow tool.
Strong answer hits
- Flow Builder is the recommended, go-forward automation tool.
- Both reached end of support on December 31, 2025.
- Existing ones still run, but you can’t create new ones; use Migrate to Flow.
Q25Name the main Flow types and give a use case for each.
The ones I use most are Screen Flows for guided user interfaces and Record-Triggered Flows that fire when a record is created, updated, or deleted. Beyond those there are Scheduled Flows for time-based batch work, Autolaunched Flows called from Apex or REST, and Platform Event-Triggered Flows for event-driven automation.
Strong answer hits
- Screen Flow: guided UI for users.
- Record-Triggered: runs on create/update/delete.
- Scheduled and Autolaunched: batch by time / called by Apex or REST; plus Platform Event-triggered.
Q26Before-save versus after-save record-triggered flow — when do you use each?
A before-save flow is the fast path — it updates fields on the same record being saved, without extra DML, similar to a before trigger. An after-save flow runs once the record is saved and is what you use to touch related records, send emails, or do asynchronous work. So for a simple same-record field update, before-save is the performant choice.
Strong answer hits
- Before-save: fast field updates on the same record, no extra DML.
- After-save: related records, emails, async actions, getting other records.
- Before-save is the performant choice for same-record changes.
Q27A record-triggered flow and a validation rule seem to fight each other. Why does order of execution matter here?
This comes down to the documented Order of Execution. Before-save flow field updates happen before validation rules run, so a validation rule can reject a value the flow just set. If I see them fighting, I trace through the save order to find which acts first and adjust the logic or criteria accordingly.
Strong answer hits
- Before-save flow field changes happen before validation rules run.
- Validation rules can block a save the flow attempted to set.
- Know the documented Order of Execution to predict the outcome.
Q28How do you keep multiple record-triggered flows on one object from causing problems?
I try to keep it to one record-triggered flow per object per timing where it’s practical, so the logic lives in one place. Where I do need more than one, I use tight entry criteria and set the Flow Trigger Order so they run in a predictable sequence. I’m also careful about recursion so a flow doesn’t re-trigger itself.
Strong answer hits
- Prefer one flow per object per timing where practical.
- Use entry criteria and Flow Trigger Order to control sequence.
- Guard against recursion and unintended re-entry.
Q29What is an approval process and what are its key components?
An approval process routes a record for sign-off through one or more steps. The core pieces are entry criteria that decide which records enter, the approvers — which can be a specific user, a queue, or a related user — and the actions for initial submission, final approval, and rejection, plus the ability to recall.
Strong answer hits
- A multi-step process to route records for sign-off.
- Entry criteria, approvers (user, queue, related user), and steps.
- Initial, final approval, final rejection, and recall actions.
Q30Declaratively, how would you alert the team when a high-value opportunity is won?
I’d build a record-triggered flow on Opportunity that runs on update. The entry criteria would be Stage equals Closed Won plus an amount threshold for “high value.” Then the action is an email alert or a Slack message — all declarative, no code required.
Strong answer hits
- Record-triggered flow on Opportunity update.
- Entry criteria:
StageName = Closed Wonand an Amount threshold. - Action: email alert or a Slack action — no code needed.
Q31When do you reach for Apex instead of Flow?
My default is declarative-first, so Flow handles the large majority of admin automation. I reach for Apex when the logic gets genuinely complex, when I need high-volume bulk performance, or for fine-grained control over callouts that Flow can’t give me. I also weigh maintainability — who’s going to own this after I build it.
Strong answer hits
- Declarative-first; Flow handles most admin automation.
- Apex for complex logic, high-volume bulk performance, fine-grained callouts.
- Weigh maintainability and who will own it long term.
Q32What is a fault path in Flow, and why does it matter?
A fault path, set with a fault connector, is how a flow handles errors from an element like a record update or a callout. It lets me route to a friendly error message, log the problem, or run cleanup logic. Without one, the user just hits an unhandled error and the whole transaction fails.
Strong answer hits
- A fault connector handles errors from an element.
- Routes to a friendly message, a log, or cleanup logic.
- Without it, users hit an unhandled error and the transaction fails.
Currency check
If a candidate recommends building new automation in Workflow Rules or Process Builder, that’s a red flag in 2026. Both are out of support as of December 31, 2025, and new ones can’t be created. The expected answer is Flow Builder.
05 — Analytics
Reports & Dashboards
Reporting questions test whether you understand how report data respects sharing and how to surface the right view to the right audience.
Q33What are the report formats, and when would you use each?
There are four. Tabular is a simple list, like a spreadsheet. Summary groups rows by one or more fields. Matrix groups by both rows and columns, good for two-dimensional analysis. And Joined lets you put multiple report blocks side by side in one view.
Strong answer hits
- Tabular: simple lists; Summary: grouped by rows.
- Matrix: grouped by rows and columns.
- Joined: multiple report blocks side by side.
Q34What is a custom report type, and why create one?
A custom report type defines which objects and related fields are even available to build a report on. You need one for custom objects and for unusual relationships. It also lets you choose “with or without” related records — for example, showing accounts that have no opportunities, which a standard type can’t do.
Strong answer hits
- Defines which objects and related fields are available to a report.
- Needed for custom objects and unusual object relationships.
- Supports “with or without” related records (e.g., accounts without opportunities).
Q35What is the difference between a standard and a dynamic dashboard?
A standard dashboard runs as one fixed running user, so everyone sees that person’s data. A dynamic dashboard runs as whoever’s viewing it, so each user sees their own data through it. The trade-offs are that dynamic dashboards are limited in number by edition and can’t be scheduled to refresh.
Strong answer hits
- Standard dashboard runs as a single fixed running user.
- Dynamic dashboard runs as the logged-in viewer — shows their data.
- Dynamic dashboards are limited per edition and can’t be scheduled to refresh.
Q36What is a bucket field, and when is it useful?
A bucket field lets you group report records into categories right inside the report, without creating a new field or formula on the object. It’s great for quick, ad-hoc grouping — like sorting deals into size tiers or grouping ages into bands — purely at the report level.
Strong answer hits
- Categorizes report records into groups within the report.
- No new field or formula on the object required.
- Good for ad-hoc grouping like age bands or deal-size tiers.
Q37Reps should each see only their own data in a shared report. How?
The good news is reports already respect sharing, so a user only sees records they have access to. On top of that I’d add a “My records” filter or scope it by the role hierarchy. And for a dashboard, I’d make it dynamic so each rep sees their own numbers.
Strong answer hits
- Reports already show only records the running user can access.
- Use a “My records” filter or role-hierarchy scope.
- For dashboards, use a dynamic dashboard so each viewer sees their data.
Q38How does folder sharing for reports and dashboards work?
Reports and dashboards live in folders, and the folder controls who can access them. You share a folder with users, roles, or groups, and you assign an access level — Viewer, Editor, or Manager — depending on whether they should just see it or be able to change it.
Strong answer hits
- Folders control who can access reports and dashboards.
- Share to users, roles, or groups.
- Access levels: Viewer, Editor, Manager.
06 — Data
Data Management & Quality
Among these Salesforce Admin interview questions, the data ones reveal whether you’ve actually loaded and cleaned production data or only read about it.
Q39Data Import Wizard versus Data Loader — when do you use each?
The Data Import Wizard is the built-in UI tool — it handles up to 50,000 records, works with standard and custom objects, and has good de-duplication options. Data Loader is the heavier tool — up to 5 million records, all objects, and it can delete and export too. Data Loader can also be scheduled or run from the command line and uses the Bulk API for large volumes.
Strong answer hits
- Import Wizard: UI-based, up to 50,000 records, built-in de-dupe options.
- Data Loader: up to 5 million records, all objects, supports delete/export.
- Data Loader can be scheduled and run via CLI; supports the Bulk API.
Q40What is the relationship between matching rules and duplicate rules?
They work as a pair. The matching rule defines how Salesforce decides two records are duplicates — which fields to compare and how. The duplicate rule then says what to do about it: allow, block, or just report the duplicate when a record is created or edited. A duplicate rule always references a matching rule.
Strong answer hits
- The matching rule defines how duplicates are identified.
- The duplicate rule decides the action: allow, block, or report.
- A duplicate rule references a matching rule to function.
Q41A bulk load created duplicate accounts. How do you clean it up and prevent a repeat?
First the cleanup — I’d run duplicate jobs or use the matching rules to surface duplicate record sets, then merge them into a single master record. To stop it happening again, I’d designate an external ID field and load with upsert, so future records match and update instead of creating new duplicates.
Strong answer hits
- Use duplicate jobs / matching rules to surface duplicate record sets.
- Merge into a master record.
- Prevent recurrence with an external ID and upsert.
Q42What is an external ID, and why use one?
An external ID is a field you flag as a unique key, usually the record’s identifier from an external system. Its big value is enabling upsert — Salesforce matches on it to either update an existing record or create a new one. That’s how you avoid creating duplicates during integrations and repeated loads.
Strong answer hits
- A field flagged as a unique key from an external system.
- Enables upsert — match-or-create on load.
- Prevents duplicates during integrations.
Q43Sketch a SOQL query that finds Accounts with no Contacts, and say where you’d run it.
I’d write an anti-join query — selecting account Ids that aren’t in the set of AccountIds on Contact — which returns accounts with no related contacts. I’d typically run it in the Developer Console’s Query Editor, or in Workbench or the new Web Console.
Strong answer hits
SELECT Id FROM Account WHERE Id NOT IN (SELECT AccountId FROM Contact).- Uses a semi-join / anti-join on the child object.
- Run it in the Developer Console Query Editor (or Workbench / Web Console).
Q44What does Mass Transfer Records do, and when would you use it?
Mass Transfer Records is a Setup tool that reassigns ownership of a large batch of records in one action. The classic use case is when a rep leaves or territories get reshuffled and you need to move all their accounts or leads to someone else. It respects the running user’s access while doing it.
Strong answer hits
- Reassigns ownership of many records at once.
- Common when a rep leaves or territories change.
- A Setup tool that respects the user’s access.
07 — Config
Configuration & Environments
Closing technical questions span the UI layer and how changes move from a sandbox to production safely.
Q45Name the sandbox types and a use for each.
There are four. Developer and Developer Pro are small, for config and development work with no production data — Developer Pro just has more storage. Partial Copy includes a sample of your production data, good for testing. And Full is a complete copy of production, used for staging and load testing. Refresh intervals get longer as the sandboxes get bigger.
Strong answer hits
- Developer and Developer Pro: config/dev work, no production data.
- Partial Copy: a sample of production data for testing.
- Full: a complete production copy for staging and load testing.
Follow-up: Which has the longest refresh interval, and why does that matter?
Q46How do change sets compare to other deployment options?
Change sets let you deploy metadata declaratively between two connected orgs, like a sandbox and production. The alternatives are managed and unmanaged packages, the Metadata API, and Salesforce DX or a DevOps tool for more mature pipelines. The big gotcha with change sets is that they can’t delete components — only add or update.
Strong answer hits
- Change sets deploy metadata between connected orgs, declaratively.
- Alternatives: packages, Metadata API, and Salesforce DX / DevOps tools.
- Change sets can’t delete components — a frequent gotcha.
Q47What are Dynamic Forms, and why do they matter now?
Dynamic Forms let you place individual fields and sections directly onto a Lightning record page and apply visibility rules at the component level — so a field can show or hide based on conditions, without needing separate page layouts and record types. They’re a big part of Salesforce’s move away from the old page-layout-driven UI.
Strong answer hits
- Place individual fields and sections on a Lightning record page.
- Apply component-level visibility rules without separate page layouts.
- Part of Salesforce’s shift away from page-layout-driven UI.
Q48A validation rule blocks a legitimate integration user. How do you handle it without disabling the rule?
I wouldn’t disable the rule, since it’s protecting everyone else’s data. Instead I’d add a bypass condition into the rule itself — usually checking for a custom permission assigned only to the integration user, or a “bypass” flag stored in a custom setting or custom metadata. The rule stays fully active for normal users.
Strong answer hits
- Add a bypass condition using a custom permission checked in the rule.
- Or a “bypass” checkbox via a custom setting / custom metadata.
- Keeps the rule active for everyone else.
08 — Behavioral
Behavioral Questions
Behavioral prompts have no factual key. Assess them on the signals a strong answer reveals — judgment, ownership, and trade-off awareness — using a STAR structure.
Q49Tell me about a time a stakeholder asked for something the platform couldn’t do as requested.
Here the interviewer wants to hear how you handle a tricky requirement, so use a STAR structure. Talk about how you dug into the real need behind the literal request, weighed configuring versus customizing, and proposed a workable alternative. The strongest answers show you managed the relationship and the expectation, not just the technical problem.
Look for
- Probing the underlying requirement, not just the literal ask.
- Configure-vs-customize judgment and a proposed alternative.
- Clear communication that managed expectations.
Red flag: Either building the literal request unquestioned, or flatly refusing with no alternative.
Q50With three releases a year, how do you stay current and decide what to adopt?
There’s no single right answer, so describe your actual routine. Mention how you read the release notes, test new features in a sandbox preview, and lean on Trailhead or the admin community. Then explain how you assess risk and communicate changes to users before rolling anything out.
Look for
- A real habit: release notes, sandbox preview, Trailhead, admin community.
- Testing changes in a sandbox before production.
- Risk assessment and communicating change to users.
Red flag: “I don’t really follow the releases” — currency is core to the admin role.
Interviewer’s High-Yield Cheat Sheet
Ten facts that most often separate a confident answer from a shaky one.
- Two security axes. Object/field access (profiles, permission sets) is separate from record access (OWD, role hierarchy, sharing). Conflating them is the #1 stumble.
- Security layer order. OLS → record access (OWD + hierarchy + sharing rules + manual + teams) → FLS → page layout.
- OWD only opens up. Sharing rules and the hierarchy extend access; nothing tightens below the org-wide default.
- Permission-set-led model. Profiles still required (one per user) for baseline; access belongs in permission sets. The profile-permissions retirement was postponed.
- Roll-up summary needs master-detail. Not available on a standard custom lookup — a classic trap.
- Many-to-many = junction object with two master-detail relationships; the first one created controls sharing.
- Flow is the automation tool. Workflow Rules and Process Builder are out of support since Dec 31, 2025; no new ones can be created.
- Before-save vs after-save. Before-save for fast same-record field updates; after-save for related records and async work.
- Dynamic dashboards run as the viewer (their own data), are edition-limited, and can’t be scheduled.
- Import Wizard vs Data Loader. 50,000-record UI tool vs the 5-million-record tool that also deletes, exports, and schedules.
Frequently Asked Questions
What topics do Salesforce Admin interviews focus on most?
▼
Most Salesforce Admin interviews concentrate on the data security and access model, declarative automation with Flow, the data model and relationships, reports and dashboards, user management, and data quality. Security and automation tend to carry the most weight because they separate confident admins from candidates who only know the click paths.
Are Workflow Rules and Process Builder still relevant in Salesforce Admin interviews?
▼
They still come up, but mostly as a currency check. Both reached end of support on December 31, 2025, you can no longer create new ones, and Flow Builder is the recommended replacement. A strong answer names Flow Builder and the Migrate to Flow tool rather than recommending the legacy tools.
Do I still need to know profiles if Salesforce recommends permission sets?
▼
Yes. Every user still requires exactly one profile, and the planned retirement of permissions on profiles was postponed. The current best practice is a permission-set-led model: use the profile for baseline settings such as default apps, page layout assignment, and login hours or IP ranges, and grant access through permission sets and permission set groups.
What is the difference between a conceptual and a scenario interview question?
▼
A conceptual question tests definitions and understanding, such as explaining the order of the security layers. A scenario question gives you a concrete problem to solve, such as granting a regional manager access to only their region’s accounts. Scenario questions are more discriminating because they reveal whether you can apply a concept under real constraints.
Which certification best supports a Salesforce Admin job interview?
▼
The Salesforce Certified Administrator (ADM-201) credential maps directly to the competencies most admin interviews probe: security, automation, the data model, reports, and data management. Working through scenario-based practice questions for that exam is one of the most efficient ways to prepare for an interview as well.
How should I answer a behavioral question in a Salesforce Admin interview?
▼
Use a STAR structure: describe the Situation, the Task, the Action you took, and the Result. Interviewers look for ownership, trade-off awareness, and good judgment about when to configure versus customize. The weakest answers either build whatever is requested without questioning it or refuse a request outright instead of proposing an alternative.
Want to go deeper on any single area? The official Salesforce Help documentation, the Apex Order of Execution reference, and the Salesforce Administrator trail on Trailhead are the sources to verify behavior against — and the same competencies appear across the broader certification track, so it’s worth a look at the full list of Salesforce certifications if you’re mapping a longer-term path.
All answer keys verified against official Salesforce sources, current to the Summer ’26 release, including the December 31, 2025 end of support for Workflow Rules and Process Builder and the postponed permissions-on-profiles retirement. Study smarter at CertifySF.com.