18 Scenario-Based Salesforce Interview Questions and Answers

Strong answer

No. I would keep the profile as the stable baseline and grant the temporary capability through a focused permission set, ideally with an assignment expiration date. Permission sets extend access without cloning or permanently widening profiles. I would name the permission set after the business task, assign it only to the approved users, and verify the effective access with User Access Summary.

I would also check whether the requirement includes record access. Object and field permissions do not automatically grant access to every record; organization-wide defaults, role hierarchy, teams, and sharing rules still matter.

Strong answer

I would first confirm whether the information belongs on an existing object, whether it needs its own lifecycle, and whether users need reporting, ownership, sharing, automation, or integrations around it. Then I would define the relationship type, required fields, data retention, expected volume, duplicate rules, and who owns data quality.

I would avoid creating an object simply because a spreadsheet has another tab. The data model should reflect business behavior, access boundaries, and reporting needs—not the current spreadsheet layout.

Strong answer

I would stop the load, preserve the failed-file evidence, and identify the matching key. Before retrying, I would configure or review matching and duplicate rules, use an External ID for deterministic upsert where appropriate, and test a representative batch in a sandbox.

For automation, I would not add a permanent global bypass casually. I would review whether the automation is bulk-safe and whether a narrowly controlled custom permission or configuration-based bypass is justified. After the load, I would reconcile source counts, Salesforce success and error files, duplicates, and key business totals.

Strong answer

Page layouts control presentation; they are not a security boundary. I would check field-level security through the user’s profile and permission sets. If the user should not read or edit the field anywhere—including reports, list views, search, API, and related lists—I would remove the corresponding field permission.

I would then verify object permission and record access separately, because Salesforce security is layered: object, field, and record access answer different questions.

Strong answer

I would confirm that the management structure really matches the required access structure. If it does, the role hierarchy can open access upward from opportunity owners to their managers. If the access cuts across roles, I would consider owner-based or criteria-based sharing rules, teams, territories, or targeted manual sharing.

I would start restrictive and open access deliberately. Sharing rules can grant wider access; they cannot make access more restrictive than the organization-wide default.

Strong answer

Not completely. with sharing helps enforce record-level sharing, but I still need to enforce object and field permissions. For user-context operations I would consider WITH USER_MODE, user-mode DML, or appropriate describe checks and Security.stripInaccessible(), depending on the use case and error-handling requirement.

I would also treat every client-provided parameter as untrusted, use bind variables for dynamic queries, and test with a least-privileged user—not only a System Administrator.

Strong answer

I would use before-save Flow for fast updates to fields on the same record before it is committed. I would use after-save Flow when the requirement involves related records, actions, notifications, or other work that depends on the record already being saved.

The choice is based on the operation, not personal preference. I would also define tight entry criteria and check whether another Flow or trigger already owns the same field to avoid conflicting automation.

Strong answer

I would inspect whether Get, Create, Update, Delete, subflow, or Apex actions sit inside loops; whether the Flow retrieves more data than needed; and whether multiple automations repeatedly update the same records. I would collect record IDs in a collection, perform database work outside the loop, and tighten entry conditions.

Then I would reproduce the issue with realistic bulk data and use debug details and logs to identify the actual limit or lock failure. “It passed the debugger for one record” is not a bulk test.

Strong answer

I add fault connectors to elements that can fail and route them to a consistent handling path. That path should capture useful context such as the Flow name, record ID, user, failed element, and fault message, then notify the correct support channel or create a durable error record.

For screen Flows, I show a useful message without exposing sensitive internals. For background automation, I make sure the error is observable and actionable rather than silently swallowed.

Strong answer

I would inspect the full transaction, not only the line named in the exception, because Flows, managed code, and other triggers share limits. The common repair is to remove SOQL and DML from loops: collect keys in Sets, query once, organize results in Maps, update Lists once, and process every record in Trigger.new.

Set<Id> accountIds = new Set<Id>();
for (Opportunity opp : Trigger.new) {
    if (opp.AccountId != null) accountIds.add(opp.AccountId);
}

Map<Id, Account> accountsById = new Map<Id, Account>([
    SELECT Id, Industry
    FROM Account
    WHERE Id IN :accountIds
]);

I would finish with a test that inserts or updates a full batch and asserts the business outcome, not merely code coverage.

Strong answer

A thin trigger delegates business behavior to classes that are easier to test, reuse, and maintain. The handler can separate before and after contexts, keep execution ordering explicit, and centralize recursion or re-entry decisions.

I would avoid presenting a framework as the goal. The goal is predictable behavior. A small org may need a simple handler; a complex org may need domain, selector, service, and unit-of-work layers. The architecture should match the complexity.

Strong answer

I start with the workload and operational requirements. Queueable is a strong general choice for discrete asynchronous work that needs complex types, a job ID, or controlled chaining. Batch is for large data sets that must be processed in manageable chunks. Scheduled Apex starts work at a planned time. Future methods still exist, but Queueable is usually easier to observe and extend.

I also ask about callouts, ordering, retries, duplicate execution, concurrency, and how support teams will know the job failed.

Strong answer

I compare metadata and configuration dependencies: missing fields, record types, permission sets, named credentials, custom metadata, API versions, installed packages, test data assumptions, and production-only automation. I read the first meaningful error rather than reacting to every downstream failure.

Then I reproduce through a validation deployment using the same artifact and test level intended for production. The fix should remove the environmental assumption, not simply weaken the test.

Strong answer

It should define the source commit and artifact, dependency order, validation results, test strategy, expected duration, business owner, pre- and post-deployment checks, user communication, monitoring, and rollback or roll-forward decision points. Data changes and manual configuration steps need owners and evidence as well.

For risky changes, I would rehearse the runbook in a production-like environment and define success metrics before the window begins.

Strong answer

Metadata rollback is a redeployment of a known-good version; it is not a magic undo button. Data changes are separate and may require backups, inverse scripts, or a roll-forward correction. Destructive changes and schema changes need special care because restoring code does not restore deleted metadata or transformed data automatically.

I would design reversibility before deployment: version-controlled metadata, protected backups, feature flags or custom metadata where appropriate, and a tested decision path for roll back versus roll forward.

Strong answer

I would use the current Named Credential and External Credential model rather than hardcoding endpoints, client secrets, or tokens in Apex or custom settings. The named credential represents the endpoint and transport; the external credential represents the authentication protocol and principals. Permission mappings control who can use it.

I would also separate non-secret environment configuration from credentials and plan how sensitive authentication material is provisioned after deployment.

Strong answer

I would make the operation idempotent. The sender supplies a stable unique request or business identifier, and the receiver stores or checks it before creating another record. A retry with the same identifier returns or updates the existing result instead of repeating the side effect.

Retries should have limits, backoff, monitoring, and a dead-letter or manual recovery path. A timeout means the result is unknown; it does not prove that the first request failed.

Strong answer

I use synchronous request–reply when the user or caller needs an immediate answer and both systems can meet the latency and availability requirement. I prefer asynchronous messaging when work can complete later, systems need loose coupling, traffic can spike, or retry and replay matter.

The answer also depends on source of truth, ordering, delivery guarantees, event volume, error ownership, and reconciliation. “Real time” should be translated into a measurable service-level requirement before choosing a pattern.

Strong answer

I would start with an assistive use case such as summarizing a long Case history and proposing the next best troubleshooting steps. The model should be grounded in approved case data and knowledge, with access filtered to the agent’s permissions. The output should be clearly labeled as generated, require human review before customer-facing action, and avoid exposing sensitive fields in prompts or logs.

I would measure handle time, summary correction rate, agent adoption, escalation quality, and unsafe or unsupported suggestions. I would begin with a small supported queue, collect feedback, and expand only when quality and governance targets are met.