Top 15 Salesforce Interview Questions and Answers in 2026

Before the Questions: What Makes a Good Salesforce Interview Answer

A few things separate candidates who clear Salesforce interviews from those who don't:

Precision over volume. Saying "Apex is Salesforce's programming language used for many things" is not an answer. "Apex is a strongly-typed, object-oriented programming language developed by Salesforce that runs on the Force.com platform and is primarily used for writing triggers, batch jobs, and custom business logic that can't be achieved through declarative tools" — that's an answer. Be specific.

Real examples when possible. Interviewers notice when candidates can tie their answers to actual project scenarios. "In one of my implementations, we used batch Apex to process 200,000 records overnight because synchronous processing would hit governor limits" signals real experience.

Honest acknowledgment of limits. If you don't know something precisely, saying "I haven't worked with that specific feature extensively, but my understanding is..." is better than guessing confidently and being wrong. Interviewers respect intellectual honesty.

Understanding the 'why' behind features. Don't just describe what something is — explain why it exists. Why does Salesforce have governor limits? Why use a trigger over a Flow? Why is a lookup relationship different from a master-detail? The 'why' shows depth.

With that baseline set — here are the questions.

Section 1: Salesforce Admin & Platform Fundamentals

These questions come up in virtually every Salesforce interview, regardless of whether the role is Admin or Developer-focused. Interviewers use them to gauge basic platform understanding.

Q1. What is the difference between a Profile and a Permission Set in Salesforce?

Model Answer:

A Profile is a mandatory assignment for every Salesforce user — every user must have exactly one Profile. It defines the baseline access level for that user: which objects they can see, which fields are visible, which page layouts are assigned, and what system-level permissions they have (like "Modify All Data" or "Manage Reports").

A Permission Set is an additive layer. It extends a user's access beyond what their Profile grants, without changing the Profile itself. A user can have multiple Permission Sets assigned simultaneously.

The practical distinction: if you have a sales rep Profile that restricts access to financial data, but one specific sales rep needs to view invoices, you'd create a Permission Set that grants read access to the Invoice object and assign it to that user alone — rather than creating an entirely new Profile just for them.

In 2026, Salesforce is strongly pushing the adoption of Permission Set Groups — a way to bundle multiple Permission Sets into a named group for easier bulk assignment. Mentioning this in your interview demonstrates you're keeping up with platform direction.

What interviewers are listening for: Candidates who explain this in terms of the use case — not just a definition. They want to see that you understand the administrative consequences of each choice.

Q2. Explain the difference between a Lookup Relationship and a Master-Detail Relationship in Salesforce.

Model Answer:

Both are relationship types between Salesforce objects, but they differ significantly in behavior and implications.

A Lookup Relationship is a loosely coupled link between two objects. The child record can exist independently of the parent — deleting the parent does not delete the child. The lookup field on the child is not required by default. There's no roll-up summary capability across a lookup relationship from the parent side (without custom solutions), and the child's sharing and security settings remain independent.

A Master-Detail Relationship is a tightly coupled, parent-child relationship. The child record cannot exist without the parent — if the parent is deleted, all child records are cascade-deleted. The master-detail field on the child is always required. Crucially, master-detail relationships enable Roll-Up Summary Fields on the parent object, which can count, sum, min, or max values from child records.

Security-wise, in a master-detail relationship, the child inherits the sharing settings of the parent. You can't independently manage the child's sharing.

A practical example: an Invoice (parent) with Line Items (child) makes sense as a master-detail, because line items don't exist without the invoice and you'd want a roll-up field showing the total invoice amount. A Contact with an optional secondary Account relationship might be a lookup, because contacts can exist independently.

What interviewers are listening for: Whether you can articulate the cascade delete behavior, roll-up summary eligibility, and the security inheritance difference — not just "master-detail is stronger."

Q3. What are Salesforce Governor Limits, and why do they exist?

Model Answer:

Governor Limits are runtime limits enforced by the Salesforce platform to ensure that no single tenant's code or automation consumes disproportionate shared platform resources. Because Salesforce is a multi-tenant cloud platform — thousands of organisations share the same infrastructure — runaway queries, infinite loops, or resource-heavy operations could degrade performance for everyone if left unchecked. Governor limits are Salesforce's technical guardrails against that.

Key governor limits in Apex (per transaction):

Maximum 100 SOQL queries
Maximum 50,000 records retrieved via SOQL
Maximum 150 DML operations (insert, update, delete, etc.)
Maximum 10,000 records processed via DML
Maximum CPU time: 10,000 ms (synchronous) / 60,000 ms (asynchronous)
Maximum heap size: 6 MB (synchronous) / 12 MB (asynchronous)

Governor limits are the primary reason Apex requires a "bulkification" approach — writing code that handles collections of records rather than processing one record at a time in a loop. A trigger that fires SOQL inside a for loop will breach the 100 SOQL query limit the moment it processes more than 100 records.

What interviewers are listening for: Not just the definition, but evidence that you understand why they exist and how they shape the way you write Apex. Candidates who can name specific limits and connect them to bulkification requirements demonstrate real platform depth.

Q4. What is the difference between Workflow Rules, Process Builder, and Flow in Salesforce?

Model Answer:

All three are declarative automation tools in Salesforce, but they represent three different generations of the platform's automation capabilities.

Workflow Rules are the oldest automation tool. They trigger on record creation or edit, can send email alerts, create tasks, update fields, and send outbound messages. They're simple but severely limited — no branching logic, no multi-object support, no ability to create records.

Process Builder was introduced as a more powerful alternative to Workflow Rules. It supports conditional branching, can create and update records across related objects, and has a visual canvas. However, Salesforce officially retired Process Builder for new development in recent releases and strongly recommends migration to Flow.

Flow is the current generation and the future of all declarative automation in Salesforce. It's significantly more powerful than either predecessor — it supports complex branching logic, loops, subflows, screen flows for user interaction, record-triggered flows (replacing most workflow and process builder use cases), scheduled flows, autolaunched flows, and platform event-triggered flows. Flow is also the only declarative tool that can meaningfully replace simple Apex for many automation scenarios.

In 2026, if you're building anything new, the answer is Flow. Workflow Rules and Process Builder are legacy tools in maintenance mode.

What interviewers are listening for: Awareness that Process Builder and Workflow Rules are deprecated for new development. Candidates who still position Process Builder as the go-to modern tool are signaling outdated knowledge.

Section 2: Salesforce Developer Questions (Apex, SOQL, Triggers)

These questions are specifically for Developer-focused interviews. Admin candidates should have working familiarity with the concepts even if they're not writing code daily.

Q5. What is a Salesforce Trigger, and what are the best practices for writing one?

Model Answer:

A Salesforce Trigger is Apex code that executes before or after specific DML events on a Salesforce object — insert, update, delete, or undelete. Triggers allow you to automate complex business logic that declarative tools can't handle.

There are two trigger types:

Before Triggers: Execute before the record is saved to the database. Used to validate or modify record values before they're committed.
After Triggers: Execute after the record is saved. Used to access system-set field values (like the auto-generated Id) or to perform operations on related records.

Trigger best practices (what interviewers actually test on):

One trigger per object. Never write multiple triggers on the same object — execution order between multiple triggers is not guaranteed, which creates unpredictable behavior. Write one trigger per object and call Handler classes to organize the logic.

Handler pattern (Trigger Framework). Move business logic out of the trigger body into a dedicated Handler class. This keeps the trigger clean, makes the code testable, and separates concerns properly.

Bulkify your code. Triggers fire for collections of records (up to 200 at a time in DML operations). Never put SOQL queries or DML statements inside a for loop — this will hit governor limits. Query outside the loop, process in the loop, perform DML after the loop.

Context variables. Use Trigger context variables correctly — Trigger.new, Trigger.old, Trigger.newMap, Trigger.oldMap, Trigger.isInsert, Trigger.isUpdate, etc. — to efficiently access trigger data.

What interviewers are listening for: The handler pattern and bulkification are the two things experienced interviewers care most about. A candidate who writes all logic directly in the trigger body and doesn't mention handler classes is signaling that they write code that's hard to maintain.

Q6. What is the difference between SOQL and SOSL in Salesforce?

Model Answer:

Both are query languages in Salesforce, but they serve different purposes and operate differently.

SOQL (Salesforce Object Query Language) is used to retrieve records from a specific object or a set of related objects. It works similarly to SQL — you specify which object you're querying, which fields you want, and filter criteria. SOQL is precise and structured. You use it when you know exactly which object(s) you're querying.

Example: SELECT Id, Name, CloseDate FROM Opportunity WHERE StageName = 'Closed Won' AND CloseDate = THIS_YEAR

SOSL (Salesforce Object Search Language) is used to search for text strings across multiple objects and fields simultaneously. It's a full-text search mechanism — similar to how a search engine works. You use SOSL when you want to find records matching a keyword across multiple objects at once.

Example: FIND {Cloud Intellect} IN ALL FIELDS RETURNING Account(Name), Contact(FirstName, LastName)

Key differences:

SOQL queries one (or related) object; SOSL searches across multiple unrelated objects
SOQL is better for precise, structured data retrieval; SOSL is better for keyword-based search
SOQL returns up to 50,000 records; SOSL returns up to 2,000 records per object
SOQL can be used in Triggers; SOSL cannot be used in Triggers (it can be used in other Apex contexts)

What interviewers are listening for: The distinction between structured data retrieval (SOQL) and full-text search (SOSL), and the limitation that SOSL cannot be used in triggers.

Q7. Explain the concept of Bulkification in Salesforce Apex.

Model Answer:

Bulkification is the practice of writing Apex code that handles collections of records efficiently, rather than processing one record at a time. It's a fundamental requirement in Salesforce development because triggers can fire for batches of up to 200 records simultaneously — and because Salesforce governor limits restrict the number of SOQL queries and DML operations per transaction, regardless of how many records you're processing.

The classic anti-pattern (what NOT to do):

// BAD — SOQL inside a loop

for (Account acc : Trigger.new) {

List<Contact> contacts = [SELECT Id FROM Contact WHERE AccountId = :acc.Id];

// Do something with contacts

}

If this trigger fires for 150 accounts, it executes 150 SOQL queries — instantly breaching the 100 SOQL query governor limit.

The bulkified approach:

// GOOD — Query outside the loop

Set<Id> accountIds = new Map<Id, Account>(Trigger.new).keySet();

List<Contact> contacts = [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accountIds];

Map<Id, List<Contact>> contactsByAccount = new Map<Id, List<Contact>>();

for (Contact c : contacts) {

if (!contactsByAccount.containsKey(c.AccountId)) {

contactsByAccount.put(c.AccountId, new List<Contact>());

}

contactsByAccount.get(c.AccountId).add(c);

}

One SOQL query. All 150 accounts handled. Governor limits respected.

The same principle applies to DML — collect all records that need to be inserted or updated, then perform a single DML operation on the collection rather than a DML statement inside a loop.

What interviewers are listening for: Whether you can write or recognize the pattern — not just describe it. Many interviewers give code samples and ask "what's wrong with this code?" — bulkification violations are a very common test case.

Q8. What is a Salesforce Batch Apex, and when would you use it?

Model Answer:

Batch Apex is a way to process large volumes of records asynchronously in Salesforce, breaking the work into manageable chunks (batches) to avoid governor limit violations.

When you have a business requirement that involves processing hundreds of thousands or millions of records — for example, nightly recalculation of a custom field across all Accounts, or mass data cleanup — a synchronous Apex process would hit governor limits immediately. Batch Apex solves this by dividing the records into batches of up to 2,000 records each (default is 200), processing each batch in its own transaction with its own governor limit allocation.

A Batch Apex class implements the Database.Batchable interface and must include three methods:

start(): Defines the scope of records to process — typically returns a SOQL query using Database.QueryLocator that can retrieve up to 50 million records.

execute(): Contains the logic that processes each batch of records. This method is called once for each batch.

finish(): Executes after all batches complete. Used for post-processing tasks like sending an email notification or triggering another process.

When to use Batch Apex:

Data migration or mass data updates affecting large record volumes
Nightly or scheduled calculations across entire datasets
Archiving or deleting large numbers of records
Any scenario where records exceed what a synchronous process can handle

What interviewers are listening for: The key distinction between synchronous Apex (single transaction, strict governor limits) and asynchronous Batch Apex (separate transactions per batch, expanded limits). Also: the interface structure and the three required methods.

Q9. What is the difference between @future methods and Queueable Apex in Salesforce?

Model Answer:

Both are asynchronous Apex execution methods, but they differ in capability and flexibility.

@future methods are annotated with @future and execute asynchronously in a future transaction. They're simple to implement but have significant limitations:

They cannot be called from another @future method or from Batch Apex
They cannot return values
They accept only primitive parameters (no sObjects directly — you pass Ids and re-query)
You can't monitor their execution status easily
Maximum 50 @future calls per transaction

Queueable Apex implements the Queueable interface and is the more modern, flexible approach to asynchronous processing:

Can be chained — a Queueable job can enqueue another Queueable, enabling sequential async processing
Can accept non-primitive types including sObjects and complex data structures
Returns a JobId that can be used to monitor the job's status via AsyncApexJob
Can be called from Batch Apex
Easier to test than @future methods

Simple rule of thumb: Use @future for simple, one-off async operations where chaining or monitoring isn't needed. Use Queueable Apex when you need more control, need to pass sObjects, or need to chain async processes.

What interviewers are listening for: Awareness that Queueable is the preferred modern approach, and understanding of why — the ability to chain jobs and pass complex data types are the key advantages.

Section 3: Salesforce Data Model and Security

Q10. How does Salesforce's security model work? Explain OWD, Role Hierarchy, Sharing Rules, and Manual Sharing.

Model Answer:

Salesforce uses a layered security model for controlling record-level access. Understanding the sequence matters — each layer can only open access wider, never restrict it more tightly than the layer before it.

Organization-Wide Defaults (OWD) set the baseline access level for every record of each object — how much access does a user have to records they don't own? OWD options are Private, Public Read Only, and Public Read/Write. OWD is your most restrictive starting point.

Role Hierarchy grants access vertically. Users higher in the role hierarchy can view (and optionally edit) records owned by users below them. It's an organizational reporting structure that also drives data visibility. If OWD is Private but the VP of Sales is above the Sales Rep in the role hierarchy, the VP can see the rep's records.

Sharing Rules grant access horizontally — to users in the same peer group who wouldn't otherwise see each other's records due to OWD. Sharing rules are criteria-based (all records matching a condition) or ownership-based (records owned by a particular role or group).

Manual Sharing allows individual record owners (or users with higher access) to manually share specific records with specific users. It's the most granular access grant, done record-by-record.

The key principle: OWD → Role Hierarchy → Sharing Rules → Manual Sharing — each layer only grants more access, never less. If you need to restrict access beyond OWD, that's done through Profiles, Permission Sets, and field-level security — not through sharing rules.

What interviewers are listening for: The sequence and the "can only open up, never restrict" principle. This is one of the most misunderstood areas of Salesforce security, so getting it right impresses interviewers significantly.

Q11. What are Salesforce Roll-Up Summary Fields, and what are their limitations?

Model Answer:

Roll-Up Summary Fields are a feature of Master-Detail relationships that allow a field on the parent object to automatically calculate an aggregate value from related child records. The four aggregate functions available are:

COUNT — counts the number of child records
SUM — sums a numeric field across child records
MIN — returns the minimum value of a field across child records
MAX — returns the maximum value

Example: An Order object (parent) with Order Line Items (child, in a master-detail relationship). A Roll-Up Summary field on Order can sum the Unit Price field across all related Order Line Items to give a "Total Order Value."

Limitations (what interviewers specifically ask about):

Only available on Master-Detail relationships — not Lookup relationships
Maximum of 25 roll-up summary fields per object
Cannot roll up across more than two levels of hierarchy (grandparent → parent → child)
Fields used in roll-up summaries cannot be used in certain types of criteria filters
Cross-object formula fields cannot reference roll-up summary fields
Recalculation can be delayed when triggered by large bulk operations

Workaround for Lookup relationships: When you need roll-up-like functionality across a Lookup relationship, you use Apex (typically a trigger or a scheduled Apex job) to calculate and update the parent field — because native roll-up summaries aren't available.

What interviewers are listening for: The master-detail dependency, the 25-field limit, and — critically — the workaround for lookup relationships. That last point separates candidates who know the feature from candidates who know the platform.

Section 4: Lightning, Integration, and Advanced Topics

Q12. What is the difference between Aura Components and Lightning Web Components (LWC) in Salesforce?

Model Answer:

Both are UI component frameworks for building custom interfaces in Salesforce Lightning Experience, but they represent two generations of the technology.

Aura Components (originally called Lightning Components) were the first-generation framework, introduced around 2015. They use Salesforce-specific JavaScript patterns and a proprietary component model. Aura is still fully functional and widely deployed, but it's no longer the recommended framework for new development.

Lightning Web Components (LWC) were introduced in 2019 and are now the recommended standard. LWC is built on modern web standards — native HTML, JavaScript (ES6+), and CSS — rather than Salesforce-proprietary patterns. This means developers with web development backgrounds can pick up LWC faster, and the components perform better because they rely on the browser's native shadow DOM rather than a Salesforce-managed virtual DOM.

Key differences:

Aspect	Aura	LWC
Technology base	Proprietary Salesforce patterns	Modern web standards (HTML, JS)
Performance	Slower (virtual DOM)	Faster (native shadow DOM)
Learning curve	Steeper for web devs	Easier for those with web background
Recommendation status	Legacy / maintenance mode	Current standard
Interoperability	Can contain LWC components	Cannot contain Aura components

Both can coexist in the same org and LWC can be embedded inside Aura components, but not vice versa.

What interviewers are listening for: Whether you know that LWC is the current standard and can articulate why it performs better (web standards, native shadow DOM). Candidates still positioning Aura as the modern choice signal outdated knowledge.

Q13. How does Salesforce handle data integration with external systems?

Model Answer:

Salesforce offers several integration patterns, and the right choice depends on the use case, data volume, and latency requirements.

REST API: The primary modern integration method. Salesforce's REST API supports JSON and XML, and is used for real-time, request-response integrations — reading, creating, updating, or deleting Salesforce records from external systems. Most modern integrations (mobile apps, web apps, third-party platforms) use the REST API.

SOAP API: Older XML-based web service API. Still widely used for enterprise-to-enterprise integrations, particularly with legacy systems that were built on SOAP-based architectures.

Bulk API: Designed for high-volume data operations — loading, updating, or deleting hundreds of thousands of records asynchronously. Used for data migration and large batch data loads rather than real-time integration.

Streaming API / Platform Events: Salesforce's event-driven integration capability. External systems can subscribe to a Salesforce channel and receive real-time notifications when records change (Streaming API) or when business events are published (Platform Events). Used for near-real-time integration without constant polling.

Outbound Messages: A declarative option in Workflow Rules that sends XML messages to external endpoints when specific conditions are met. Being replaced by Platform Events in modern architectures.

MuleSoft and Integration Middleware: For complex enterprise integration scenarios, Salesforce recommends MuleSoft (which it acquired in 2018) as an integration middleware layer. This isn't Salesforce-native but is closely associated with the ecosystem.

What interviewers are listening for: Awareness of multiple integration patterns and the judgment to choose the right one for different scenarios. REST for real-time, Bulk for volume, Platform Events for event-driven — that's the framework interviewers want to see.

Q14. What is Apex Test Class, and why is it mandatory in Salesforce?

Model Answer:

An Apex Test Class is a class written specifically to test the behavior of your Apex code. Salesforce mandates that any Apex code deployed to a production org must have at least 75% code coverage verified by test classes — and every test must pass.

This isn't optional or a best practice suggestion. It's a hard deployment requirement enforced by the platform. If your test coverage drops below 75%, or if any test fails, you cannot deploy to production.

Why Salesforce mandates test coverage:

It forces developers to write code that's testable — which generally means better-designed, more modular code
It provides a safety net against regressions when platform upgrades or code changes are deployed
Salesforce regularly runs all org test classes during its release upgrades to verify that existing implementations don't break

Key testing principles:

@isTest annotation: Test classes must be annotated with @isTest. Test methods within the class are annotated with @isTest or declared as static testmethod.

Test.startTest() and Test.stopTest(): These methods reset governor limits for the test execution block, giving you a clean limit allocation to test your logic properly.

Test data: Best practice is to create test data within the test class using @testSetup methods rather than relying on existing org data (which makes tests brittle and non-portable).

Assertion: Use System.assertEquals(), System.assertNotEquals(), and System.assert() to verify that your code produces the expected outcomes — not just that it runs without errors.

What interviewers are listening for: Understanding that 75% is a platform requirement (not just a guideline), the purpose of Test.startTest()/stopTest(), and the importance of assertions — not just achieving coverage for its own sake.

Q15. What is a Salesforce Sandbox, and what are the different types?

Model Answer:

A Salesforce Sandbox is a copy of a production organization used for development, testing, and training — without affecting live data or real users. All Salesforce development best practice assumes you build and test in sandbox first, then deploy to production.

Salesforce offers four types of sandboxes, each with different data storage, metadata refresh frequency, and purpose:

Developer Sandbox:

Smallest storage allocation (200 MB data, 200 MB file storage)
Contains only metadata (configuration, code, schema) — no production data
Can be refreshed every day
Used for: individual developer work, code writing, unit testing
Included in all Salesforce editions

Developer Pro Sandbox:

Slightly larger (1 GB data storage)
Still metadata only, no production data
Can be refreshed every day
Used for: slightly larger development or integration testing

Partial Copy Sandbox:

5 GB data storage
Includes a representative sample of production data (based on a Sandbox Template you define)
Can be refreshed every 5 days
Used for: QA testing and UAT where real data patterns are needed for realistic testing

Full Sandbox:

Full copy of production — all data, all metadata, full storage
Can be refreshed every 29 days
Most expensive sandbox type (significant additional cost)
Used for: performance testing, load testing, final UAT before major releases

The typical development workflow: Developer Sandbox → Developer Pro → Partial Copy (QA) → Full Sandbox (UAT) → Production

What interviewers are listening for: The four types and their distinguishing characteristics — particularly the data inclusion difference (metadata-only vs. data copy) and the refresh frequency. Many candidates know "Developer" and "Full" sandboxes but can't describe Developer Pro or Partial Copy accurately.

Bonus: Interview Tips Specifically for Salesforce Roles in 2026

Beyond knowing the answers, a few practical things help in Salesforce interviews:

Build your Trailhead profile before interviewing.