Salesforce Scenario Based Interview Questions and Answers

Scenario rounds are where admin and junior developer interviews are won or lost. The panel stops asking what a sharing rule is and describes a business problem instead: a manager who cannot see his team's pipeline, a field that must be mandatory for one region only, a record that keeps getting edited after approval. You are expected to name the feature, justify it against the obvious alternative, and survive the follow-up.

Below are 16 scenarios from real interview rounds, weighted towards declarative configuration. Each answer gives the setup, the reasoning, and the question that lands next.

Sharing, visibility and record access

This is the usual opening theme, because it separates people who have configured an org from people who have watched a video about it.

A user should see only their own records. How would you implement this?

Set the Organization-Wide Default for that object to Private. OWD is the floor of the access model, and every other feature can only open access up from there, never close it down. With Private, a user sees records they own, records shared to them, and records owned by people below them in the role hierarchy.

That last part is the catch. If the requirement is strictly own records only, Private alone is not enough for anyone who sits above someone else in the hierarchy. On a custom object, uncheck Grant Access Using Hierarchies in sharing settings. On standard objects that checkbox is locked on, so you either flatten the roles for those users or accept the hierarchy access. Then add nothing further.

Follow-up they will ask: what changes when Grant Access Using Hierarchies is switched off, and where a restriction rule fits better than changing OWD.

A manager needs access to team records automatically. What feature helps?

Role hierarchy. A user in a higher role automatically gets access to records owned by users in roles below them, with no sharing rule written. Put the manager in a parent role, the reps in child roles, and access follows the org chart as people join and leave.

The wrong answer is a sharing rule per manager. That works on day one and is unmaintainable by month three, because every new manager needs a new rule.

Say two things out loud. Hierarchy access flows upward only, so the manager sees the rep's records and not the reverse. And a matrix manager who is not above the reps gets nothing from it, so there you fall back to a sharing rule on a public group.

Follow-up they will ask: the manager also needs records from a peer team. Now what, and why does the answer change.

How do you give temporary access to records for a project team?

Create a public group containing the project team, then write a sharing rule that shares the relevant records with that group at Read Only or Read/Write. When the project ends, remove the members from the group and the access goes with the next sharing recalculation. The rule stays in place for the next project.

The point of the group is indirection. You never name individual users inside the sharing rule, so changing the team is a membership change rather than a configuration change.

Manual sharing is the alternative, and it suits one record and one user. Manual shares also disappear when the record owner changes, which surprises people in production.

Follow-up they will ask: owner-based versus criteria-based sharing rules, and what happens to sharing when a user moves role.

How would you secure sensitive fields so only certain users can see them?

Use field level security, granted through permission sets rather than edited on every profile. Hide the field in the profiles, create one permission set such as Salary Field Access that grants Read or Edit, and assign it to the few users who need it. Access becomes one assignment, visible in one place and easy to remove.

Field level security is enforced everywhere the field appears, including reports, list views, search and the API. That is why it beats removing the field from the page layout. A layout is presentation only, and the field is still reachable through a report.

One caveat worth raising, because it shows real experience: a formula field can surface the value of a field the user is not allowed to see.

Follow-up they will ask: profile versus permission set versus permission set group, and how you would grant this access for two weeks only.

Record types, page layouts and the interface

Different users need different page layouts for the same object. What would you do?

Create record types and assign a different page layout per record type per profile. The layout assignment grid in Setup is a matrix of profile against record type, so one profile can get a short layout on one record type and a full layout on another.

This beats building a separate custom object, because the data stays in one object and reports, list views and roll-ups still work across the whole set. Record types also filter picklist values, which is normally part of the same requirement.

If the business process is identical and only the visible fields differ, you may not need a record type at all. Profile-based layout assignment does it with less configuration, and record types are hard to remove later, so not reaching for them automatically counts in your favour.

Follow-up they will ask: how many record types would you create, and what does a user see when they have access to two.

Users complain about too many fields on the page. What is the solution?

First, audit the layout with the business and remove what is genuinely unused. That is the honest answer and usually the right one.

After that, the configuration choice is Dynamic Forms. It breaks the layout into individual fields and sections on the Lightning record page, and each one carries a visibility rule based on the record's own values, the user's profile, or a permission. A commission field appears only on closed won opportunities. An escalation section appears only for support managers.

A lean page layout per profile does a cruder version of this. Dynamic Forms is stronger because the condition can sit on the record and not only on the user.

Follow-up they will ask: how field level security, page layout and Dynamic Forms visibility interact when all three touch the same field.

Different sales processes require different opportunity stages. How is this handled?

Create one sales process per stage set, then one record type per sales process, and point each record type at its process. The sales process controls which values from the Stage picklist are available. The record type is what the user picks when creating the record. Assign the record types to the right profiles and set a default per profile.

New business and renewals is the standard example. New business runs through qualification, proposal and negotiation. Renewal skips most of that. Same object, same reports, different process.

Forecast category and probability are tied to the stage value itself and shared across processes, so two processes needing different probabilities need two distinct stage values.

Follow-up they will ask: the same pattern exists for Case and Lead. What are those called, and which picklist does each control.

Validation, data quality and duplicates

A field must be mandatory only for certain users. How can you achieve this?

Write a validation rule that fires only for the users in scope. It checks that the field is blank and that the running user falls in the target group, and returns true to block the save.

AND(
  ISBLANK( Discount_Approval_Note__c ),
  ISPICKVAL( StageName , "Negotiation/Review" ),
  NOT( $Permission.Skip_Discount_Note )
)

Drive the exception from a custom permission rather than hardcoding a profile ID. Hardcoded IDs break on deployment to another org, and nobody remembers what 00e5g000... referred to six months later. With a custom permission you assign it through a permission set and the rule never changes again.

Marking the field required on the page layout is the wrong answer, because that applies to everyone on the layout and does not apply to API inserts or data loads. A validation rule runs at the database layer, so imports and integrations obey it too.

This is where memorised definitions collapse. Anyone can say "use a validation rule." The interviewer then says give me a real project example, and the answer has to include which object, which field, what the business was stopping, and who got the exception.

Follow-up they will ask: how you stop this rule breaking the nightly data load, and the difference between ISBLANK and ISNULL.

You need to prevent duplicate records. What feature would you use?

Matching rules and duplicate rules together. The matching rule defines what counts as the same record, using exact or fuzzy matching on the identifying fields, for example company name fuzzy plus email exact. The duplicate rule decides what happens on save: allow with an alert, or block, and whether to report the match.

Configure it per action. A common pattern is block on create and allow with alert on edit. You also choose whether the rule applies to records created through the API, which matters when an integration or a data loader feeds the object.

Two limits worth raising. Duplicate rules act at the moment of save, so they do nothing about duplicates already sitting in the org. And a fuzzy rule that is too loose blocks legitimate records, so test the matching rule against real data before moving from alert to block.

Follow-up they will ask: how you deal with the duplicates already there, and how you would match Leads against Contacts.

Approval processes and locking records

A business process requires multiple approval levels. How would you implement it?

Build one approval process with multiple approval steps. Each step has its own criteria, approver and actions, and the record reaches the next step only after the current one approves.

Settings to name: entry criteria decide which records can be submitted at all, initial submission actions lock the record by default, step criteria let higher steps be skipped when they do not apply, and one step can hold several parallel approvers set to unanimous or first response. Final approval and final rejection actions are where you set status fields and send notifications.

Interviewers go five levels deep here. Which object, what the requirement was, why three steps and not two, who the approver was, what happened on recall. Fabricated project experience does not survive that.

Follow-up they will ask: what happens when the approver is on leave, and how you pull back a submitted record.

Users should not edit records after approval. How would you enforce this?

Two layers, and you should describe both.

The approval process locks the record while it sits in the queue, and keeping it locked is a standard final approval action, so choose that rather than releasing it. Administrators can still edit locked records when that option is switched on in approval settings, which is usually what you want for corrections.

Locking is all or nothing though, and most requirements are narrower. If the commercial fields must freeze while status and activity fields stay editable, release the lock and enforce it with a validation rule instead.

AND(
  ISPICKVAL( PRIORVALUE( Approval_Status__c ), "Approved" ),
  OR( ISCHANGED( Amount ), ISCHANGED( Discount__c ) ),
  NOT( $Permission.Edit_Approved_Deals )
)

Follow-up they will ask: the record is locked, so how does your automation still update a field on it, and who can edit a locked record.

Choosing the right automation

Naming the right tool, and defending the choice, is the part of the scenario round that most separates candidates.

How would you automatically assign leads to different sales reps?

Lead assignment rules. One rule is active at a time and it holds ordered rule entries. Each entry has criteria, for example Country equals India and Industry equals Banking, and an assigned owner that can be a user or a queue. Salesforce evaluates entries in order and stops at the first match, so entry order is part of the design. Set a default lead owner so nothing falls through.

Assignment rules fire automatically for Web-to-Lead and lead imports. On manual creation they fire when the Assign using active assignment rule checkbox is ticked, which you can force on through the page layout.

The alternative is a record-triggered flow that sets OwnerId, and it wins when assignment depends on something the criteria builder cannot express, such as round robin or a territory lookup. For plain criteria routing, assignment rules are easier for a business admin to maintain.

Follow-up they will ask: how you would build round robin, and what happens to assignment when a lead is converted.

Users must receive an email when a record is created. How do you implement it?

A record-triggered flow on create, calling an email alert or a Send Email action. Build the template first, then the email alert, which holds the template plus the recipients, then call it from the flow. Recipients can be a user, a role, a public group or an email field on the record, with an org-wide address as sender.

Prefer the email alert when the message must be a maintained template the business can edit. Use Send Email for a short one-off message assembled inside the flow.

Emails from alerts count against a daily org limit for external addresses, so a high volume object needs thought. Give the flow entry criteria too, otherwise every insert including data loads sends mail.

Follow-up they will ask: the email must go only for records created by one team. Where does that condition sit, and why not in the email alert.

Users need guided screens to enter information step by step. What should you build?

A screen flow. Screens collect input, decision elements branch the path, and get, create and update elements read and write records along the way. Surface it as a quick action, a button, a Lightning page component or an Experience Cloud page, depending on where the user starts.

Screen flow is the answer whenever the requirement says guided, or wizard, or the user must not reach step two before finishing step one. A page layout cannot enforce sequence, and a validation rule enforces completeness only after the user presses save.

Design points that impress: use a record variable so the record is created once at the end rather than on every screen, handle the fault path on each DML element, and remember that a screen flow launched by a user runs in that user's context unless you set it to run in system context.

Practise how you narrate this one. Situation, approach, reason, result. Not "actually sir basically in our project we had one requirement." Say what the business needed, what you built, why that tool, and what changed after go live.

Follow-up they will ask: how the user goes back a screen and keeps their entries, and how you test a screen flow before release.

You need to update a related record when a record is inserted. What would you use?

Start with a record-triggered flow on after-save. It gets the related record and updates it declaratively, and it is the maintainable choice for a straightforward parent update such as rolling a status onto the Account when a Case is created.

Move to an Apex trigger when the logic outgrows the tool: complex branching across several objects, recursion control, error handling that must roll the whole transaction back, or volumes where flow element count and CPU time become a problem.

Two neighbouring cases decide themselves. To set a field on the record being saved, use a before-save flow, which writes the value before the record reaches the database. For a count or a sum of children in a master detail relationship, use a roll-up summary field and write no automation at all.

Follow-up they will ask: the order of execution between your flow, a validation rule and a trigger, and how you stop two automations updating each other in a loop.

A nightly job must update thousands of records. What solution works?

A schedule-triggered flow for the simpler case, batch Apex for the heavy one.

A schedule-triggered flow runs daily at a chosen time against an object and a filter that decide which records it touches. It processes them in batches automatically and needs no code, which makes it the right first answer for something like flagging opportunities with a close date in the past.

Batch Apex is the answer when the volume is large or the logic is real. It processes in chunks with fresh governor limits per chunk, can hold state across chunks, and gives you a finish method for a summary email or a chained job.

Answer with the decision rule rather than one tool. Declarative first, code when the volume or the logic demands it, and be ready to say which threshold made you switch.

Follow-up they will ask: what happens when the nightly job fails halfway, and how you would make it restartable.

What the interviewer is actually checking

• On sharing, whether you know the access model is layered and only ever opens up from OWD. Anyone who answers a visibility scenario with "give them a permission set" has not built one.
• On record types and layouts, whether you can tell a presentation problem from a process problem. Record types are for different processes. Layouts and Dynamic Forms are for different views of the same process.
• On validation and duplicate rules, whether you have felt the consequences: a rule that blocked the data load, a matching rule too loose to switch on, a hardcoded profile ID that broke in production.
• On approvals, whether you can describe the whole lifecycle including submission, recall, rejection and the record lock, not only the happy path of three approvers saying yes.
• On automation choice, whether you have a rule for picking a tool and can defend it. Flow, Apex or a roll-up summary can each be correct. Only one of them is correct for the requirement in front of you.

Preparing for the scenario round

Take each scenario above and rebuild it in a developer org. Set the OWD, break it, watch what the second user can see. Submit a record for approval and try to edit it. Write the validation rule, run a data load through it, watch the load fail. Configuration you have performed once is configuration you can describe under pressure, and that is the difference the panel is measuring.

If you want that practice guided, with project work you can actually defend in an interview, look at the Salesforce training in Pune with placement support at RizeX Labs, where these scenarios are built and broken in a live org rather than read from slides.