Salesforce Admin Interview Questions and Answers (2026)

25 Salesforce administrator interview questions asked in 2026 — data model, the security and sharing model, Flow automation, data management, reports, releases and real troubleshooting scenarios — with clear answers and notes on what interviewers are checking.

Quick Answer: Salesforce admin interviews concentrate on five areas — the data model (relationships, roll-ups, record types), the security and sharing model, Flow automation, data management and reporting, and releases with real-world scenarios. Security and sharing are tested most heavily. In 2026, interviewers also expect you to know that Flow has replaced Workflow Rules and Process Builder, and to have a basic understanding of how admins configure Agentforce.

Salesforce administrator roles remain one of the most common entry points into the Salesforce ecosystem in India, with steady hiring at IT services firms, consulting partners and global capability centres. The interview pattern is consistent: a few questions on the data model, a deep dive into security and sharing, a section on automation, and at least one scenario where you must solve a business problem on the spot.

The 25 questions below are grouped the way interviews usually run, with answers you could give in the room and notes on what the interviewer is listening for.

Part 1: Data Model and Configuration (Q1–6)

Q1. What is the difference between a lookup and a master-detail relationship?

A master-detail relationship is tightly coupled: the detail record cannot exist without its master, deleting the master deletes the details, the detail inherits ownership and sharing from the master, and you can create roll-up summary fields on the master. A lookup is loosely coupled: the child can exist on its own, has its own owner and sharing, and deleting the parent does not delete the child by default. An object can have at most two master-detail relationships.

What they are checking: whether you can explain the consequences — ownership, sharing, deletion, roll-ups — not just the definitions.

Q2. What is a junction object?

A custom object with two master-detail relationships, used to model a many-to-many relationship. For example, a Course Enrolment object linking Student and Course lets one student join many courses and one course have many students. The first master-detail created becomes the primary relationship, which affects the junction record's look and ownership.

Q3. What are roll-up summary fields, and what are their limits?

They calculate COUNT, SUM, MIN or MAX from related detail records onto a master record — total order value on an account, for instance. They are available on master-detail relationships (and on a few standard relationships, such as Opportunities on Account). For lookup relationships, admins use Flow or tools that emulate roll-ups.

Q4. When would you use a formula field instead of a roll-up summary?

A formula calculates from fields on the same record or its parents, at the moment the record is viewed, and is not stored. A roll-up aggregates from child records and is stored. Use a formula for things like days since last contact or a discounted price; use a roll-up for totals and counts across children.

Q5. What are record types, and how do they relate to page layouts?

Record types let one object support different business processes — different picklist values, page layouts and, for some objects, sales or support processes. A business-to-business and a business-to-consumer opportunity might use different stages and fields. Page layouts are assigned by the combination of profile and record type. Dynamic Forms on Lightning record pages add finer control, showing fields and sections based on conditions.

Q6. What is the difference between a profile and a permission set?

Every user has exactly one profile, which sets baseline settings and access. Permission sets add access on top of the profile, and a user can have many; permission set groups bundle them. Salesforce recommends keeping profiles minimal and managing most permissions through permission sets and groups, which makes access easier to manage as roles change.

What they are checking: awareness of the current best practice. Answers that put all access in profiles sound dated in 2026.

Part 2: Security and Sharing (Q7–12)

The most heavily tested area. Expect at least three of these, and at least one troubleshooting scenario built on them.

Q7. Explain the layers of Salesforce security.

Four layers, from broadest to narrowest. Organisation level: who can log in, when and from where — login hours, IP ranges, password and session policies, multi-factor authentication. Object level: whether a user can create, read, edit or delete records of an object, through profiles and permission sets. Field level: which fields they can see or edit. Record level: which specific records they can access, through the sharing model.

Q8. What are organisation-wide defaults (OWD)?

OWDs set the baseline record access for each object — Private, Public Read Only, Public Read/Write, or Controlled by Parent for detail objects. The principle is to set OWD to the most restrictive level any user needs, then open access up with role hierarchy, sharing rules and other tools. Sharing rules cannot reduce access below the OWD.

What they are checking: that you know the 'start restrictive, open up' principle.

Q9. How does the role hierarchy affect access?

Users higher in the role hierarchy can access records owned by users below them, as long as Grant Access Using Hierarchies is enabled for that object (it is always on for standard objects). The role hierarchy reflects reporting lines for data visibility; it is separate from profiles, which control what users can do.

Q10. What are the types of sharing rules?

Owner-based sharing rules share records owned by members of a group or role with another group or role. Criteria-based sharing rules share records that meet field conditions — all accounts in the Pune region with a regional team, say. Both only extend access. Where access must be narrowed for certain users, restriction rules are the tool.

Q11. What other ways can records be shared?

Manual sharing by the record owner or someone above them; account, opportunity and case teams; queues, where members can access records owned by the queue; public groups used in sharing rules; and, in Experience Cloud sites, sharing sets for external users. Developers can also use Apex managed sharing for complex rules.

Q12. How do you troubleshoot a user who cannot see a record?

Work through the layers in order. Check that the user's profile and permission sets grant read access to the object. Check field-level security if a field is missing. Then check record access: the OWD, the owner and role hierarchy, sharing rules, teams and manual shares. The Sharing Hierarchy button on the record shows who has access and why, and logging in as the user, where permitted, confirms what they see.

What they are checking: a structured approach. Jumping straight to "give them System Administrator" is the classic wrong answer.

Part 3: Automation (Q13–17)

Q13. Which automation tools should an admin use in 2026?

Flow is the main declarative automation tool. Workflow Rules and Process Builder have reached end of support, so new automation is built in Flow and existing automation should be migrated. Validation rules, approval processes, and assignment, escalation and auto-response rules remain in use for their specific purposes.

What they are checking: that you are current. Proposing Process Builder for new work is an immediate red flag.

Q14. What types of Flow are there?

Screen flows guide users through screens; record-triggered flows run when records are created, updated or deleted; schedule-triggered flows run at set times over a batch of records; autolaunched flows are called from other automation, Apex or APIs; and platform event-triggered flows respond to events. Record-triggered flows can run before save, for fast updates to the same record, or after save, for related records and actions.

Q15. When would you use a before-save versus an after-save record-triggered flow?

Use before-save to update fields on the triggering record itself — it is much faster because no extra save is needed. Use after-save when you need the record ID, need to create or update related records, send emails or call other actions.

Q16. Write a validation rule that requires a reason when an opportunity is marked Closed Lost.

A formula such as AND(ISPICKVAL(StageName, "Closed Lost"), ISBLANK(Loss_Reason__c)) with an error message on the Loss Reason field. Mention that validation rules run on save from every source — user interface, imports and integrations — so they should be written carefully and tested with data loads in mind.

Q17. How would you prevent a flow from causing problems at scale?

Avoid queries and updates inside loops — collect records and update them once; add entry conditions so the flow runs only when relevant fields change; avoid several flows on the same object that conflict, and define their order where needed; handle faults with fault paths; and test with bulk data loads, not just single records.

Part 4: Data Management and Reporting (Q18–21)

Q18. When do you use Data Import Wizard versus Data Loader?

The Data Import Wizard is browser-based and suits up to 50,000 records for common standard objects and custom objects, with built-in duplicate checking. Data Loader is a client application for larger volumes — up to millions of records — and supports all objects plus export, update, upsert and delete operations. Use external IDs with upsert to load data without first looking up Salesforce IDs.

Q19. How do you prevent duplicate records?

With matching rules, which define how records are compared, and duplicate rules, which decide what happens when a match is found — block the save or allow it with a warning and report on it. For existing duplicates, merge records and fix the source of the duplication, such as a web form or integration.

Q20. What report formats are available, and when would you use each?

Tabular for simple lists; summary for grouping rows with subtotals; matrix for grouping by both rows and columns; and joined for combining several report blocks. Report types define which objects and fields are available. Bucket fields, row-level formulas and summary formulas add analysis without changing the data model.

Q21. What is a dynamic dashboard?

A dashboard that runs as the logged-in viewer, so each person sees data according to their own access, rather than as a fixed running user. It is useful for showing each sales rep their own pipeline with one dashboard instead of many. Dynamic dashboards have limits on how many an org can have.

Part 5: Releases and Real Scenarios (Q22–25)

Q22. What types of sandbox are there?

Developer and Developer Pro sandboxes copy configuration only, with limited storage, for building and unit testing. Partial Copy adds a sample of data selected by a template, for testing and training. Full sandboxes copy all data and configuration, for performance testing, staging and user acceptance testing. Each type has its own refresh interval.

Q23. How do you move changes from sandbox to production?

Common options are change sets between connected orgs, the Salesforce CLI with source control for teams using a DevOps process, and DevOps Center for a guided, source-controlled approach. Whatever the method, validate the deployment first, include dependent components, and plan for things that do not deploy, such as some settings that must be configured manually.

Q24. A sales manager wants reps to see only their own opportunities, but managers to see their team's. How do you set it up?

Set the Opportunity OWD to Private, build a role hierarchy that reflects reporting lines with Grant Access Using Hierarchies on, and assign users to the right roles. If certain teams also need to see each other's deals, add criteria- or owner-based sharing rules. Test by logging in as a rep and as a manager.

What they are checking: that you reach for the sharing model, not for profiles, to solve record visibility.

Q25. How does Agentforce affect the admin role?

Admins increasingly configure AI agents: defining topics and instructions, building Flow-based actions the agent can call, managing what data and permissions the agent has, and testing and monitoring its responses. The underlying skills are classic admin skills — clean data, sound security and reliable Flows — applied to a new feature, which is why strong fundamentals matter more, not less.

How to Prepare

Practise in a free Developer Edition org rather than only reading. Build a small data model with a master-detail and a lookup, set OWDs to Private and test access as different users, create a role hierarchy and sharing rules, and build at least one before-save and one after-save record-triggered Flow. Load a few hundred records with Data Loader and build reports and a dashboard on them.

Prepare two or three short stories from your practice or projects: a security issue you diagnosed, an automation you built and why you chose Flow over code, a data problem you cleaned up. Interviewers remember concrete examples far longer than definitions.

Be honest about experience. If your knowledge comes from training and practice rather than a client project, say so plainly and talk about what you built. Our Salesforce course covers administration, the security model, Flow, data management and reporting with hands-on practice and mock interviews built around questions like these.

People Also Ask / FAQ

Is the Salesforce Administrator certification required for interviews?

Not strictly, but it is widely expected for admin roles and helps freshers get shortlisted. Practical ability in the interview still decides the outcome.

Do Salesforce admins need to know coding?

No. Formula syntax and a basic understanding of what Apex can do help, but admin work is declarative. Flow is the key automation skill.

Which topic is asked most in admin interviews?

Security and sharing — OWDs, role hierarchy, sharing rules, profiles and permission sets — usually with a scenario where a user cannot see a record.

Are Workflow Rules and Process Builder still asked about?

Mainly as "how would you migrate them to Flow?" Both have reached end of support, so new automation should be built in Flow.

How long does it take to prepare for a Salesforce admin interview?

With admin training complete, two to four weeks of hands-on practice and mock interviews is typical.

Get Interview-Ready as a Salesforce Admin

Live classes online and in select cities across India Explore the Salesforce Course