Salesforce Developer Interview Questions

Preparing for a Salesforce Developer Interview Questions involves mastering multiple areas – from the fundamentals of data modeling to advanced deployment strategies. Whether you’re a fresher stepping into your first Salesforce role or an experienced developer moving to a new position, this guide covers everything you need to succeed. We’ve structured this based on real interview patterns and feedback from hiring managers at companies like us.

Part 1: Data Modeling & Core Concepts

1. What is Salesforce Data Model, and How Do You Use Schema Builder?

The Salesforce data model defines how objects, fields, and relationships work together to store and organize your data. Think of it as the blueprint of your Salesforce instance.

Schema Builder is a visual tool that helps you design and understand your data model. You can view all your objects and their relationships in one canvas. It’s incredibly useful for complex data models because you get a bird’s-eye view of how everything connects. You access it through Setup > Schema Builder.

When creating relationships in Schema Builder, you’ll see colored lines: red for master-detail relationships and blue for lookup relationships. You can drag and drop objects into the canvas, create new fields, and establish relationships without writing a single line of code.

2. What Are Objects and Fields? What’s the Difference Between Standard and Custom Objects?

Objects store data in records. Think of them as database tables. Fields are the columns within those objects where specific data lives.

Standard Objects come pre-built with Salesforce – Account, Contact, Opportunity, Lead, etc. These serve the core CRM functions and are available to every Salesforce org.

Custom Objects are objects you create to fit your specific business needs. If you manage real estate properties, you might create a “Property” object. A bank might create a “Loan Application” object. You create custom objects when standard objects can’t capture your unique business processes.

Each object has standard fields too – like CreatedDate, LastModifiedDate, and OwnerId – which Salesforce automatically maintains.

3. How Many Types of Object Relationships Exist, and When Do You Use Each?

There are six main relationship types. Understanding when to use each is critical for building solid data architecture.

• Lookup Relationship: The loosest connection. The child object can exist without a parent. If you delete the parent, the child remains (lookup field becomes blank). One Account can have many Contacts through a lookup relationship. Use lookups when the relationship is optional or flexible.
• Master-Detail Relationship: Tight connection where the child is subordinate to the parent. Delete the parent, and all children are automatically deleted. The child inherits the parent’s owner and sharing settings. Useful for dependent data – like Expense Reports and Expense Line Items. You’re limited to two master-detail relationships per custom object.
• Junction Object: Creates many-to-many relationships using two master-detail relationships. A Doctor has many Patients, and each Patient has many Doctors. You’d create a junction object called “DoctorPatient” to manage this complex relationship.
• Self Relationship: An object related to itself – like Employees and Managers (both are User records). Must be a lookup relationship, not master-detail.
• Hierarchical Relationship: Only available on the User object. Creates organizational hierarchies for reporting structures.
• External Relationship: Connects to external objects from Salesforce Connect, linking to data outside your Salesforce org.

Part 2: Security & Access Control

4. Explain the Security Model – OWD, Sharing Rules, Roles, and Profiles

Salesforce security operates in layers. Understanding each layer is essential for protecting data and building secure applications.

Organization-Wide Defaults (OWD) sets the baseline. This is the starting point for all data access. Three options exist: Private (most restrictive), Public Read-Only, and Public Read/Write. OWD can only be relaxed by other mechanisms – it can never be made more restrictive by rules below it. If OWD is Private, no one except the owner sees records unless granted access through other mechanisms.

Role Hierarchy allows users higher in the hierarchy to see and edit records owned by users below them. This mirrors organizational structure. It’s powerful for implementing reporting relationships but remember – it only adds access, never restricts it.

Profiles define object-level permissions (CRUD: Create, Read, Update, Delete). Every user must have exactly one profile. Profiles also control field-level visibility and system permissions. They’re mandatory and form the foundation of access control.

Permission Sets add additional permissions on top of the profile. A user can have multiple permission sets, and the permissions accumulate. Useful for granting temporary access or project-specific permissions without changing someone’s permanent profile.

Sharing Rules create exceptions to OWD, typically to share groups of records. You can say “All sales reps can see all accounts owned by their manager” using criteria-based sharing rules.

Manual Sharing lets users manually share individual records with colleagues when needed.

5. What Are CRUD, FLS, and How Do You Enforce Them in Apex?

CRUD (Create, Read, Update, Delete) controls object-level access. Can you even touch the Account object? That’s CRUD.

FLS (Field-Level Security) controls which fields within an object you can see and edit. You might have read access to the Account object but not access to the “Annual Revenue” field if that’s sensitive information.

Both are controlled through profiles and permission sets. But here’s the catch – Apex runs in system mode by default, ignoring all security. Your code can query and modify data even if the running user shouldn’t have access.

To enforce security in Apex, use these approaches:

WITH SECURITY_ENFORCED in SOQL (simplest):

List<Account> accounts = [SELECT Id, Name FROM Account 
                          WITH SECURITY_ENFORCED LIMIT 10];

Schema methods (more control):

if (Schema.sObjectType.Account.fields.Name.isAccessible()) {
    // User can read Name field
}

Security.stripInaccessible() (removes unauthorized fields):

accounts = (List<Account>) Security.stripInaccessible(
    AccessType.READABLE, accounts).getRecords();

Part 3: Data Model & Configuration

6. What Are Formula Fields and Roll-Up Summary Fields? When Do You Use Each?

Formula Fields calculate values based on other field values in the same record. They’re read-only – users can’t manually enter data. Example: A custom field that calculates “Days Until Close” by subtracting today’s date from the Close Date. Formula fields are processed instantly when records load, but they count toward your formula size limits.

Roll-Up Summary Fields aggregate data from related child records. Only available on the parent side of master-detail relationships. You can sum, count, min, or average child record values. Example: On an Account, sum all Opportunity amounts to see total pipeline.

The key difference: Formula fields work within a single record. Roll-ups aggregate across related records through master-detail relationships.

7. What Is Data Loader and When Would You Use It?

Data Loader is a desktop application for bulk importing, exporting, updating, or deleting data in Salesforce. You’re preparing to migrate 500,000 historical records? Data Loader is your tool. It handles data manipulation without needing API calls or complex coding.

Key operations:

• Insert: Add new records in bulk
• Update: Modify existing records using an external ID
• Upsert: Insert if new, update if exists (based on External ID)
• Delete: Remove records in bulk
• Export: Backup or extract data

Data Loader runs on your local machine and processes data in batches, making it perfect for one-time migrations or scheduled data synchronization. You can also use it through the command line for automation.

Part 4: Apex Development & Triggers

8. What Are Triggers, and When Should You Use Them Instead of Flow?

An Apex Trigger is code that automatically executes in response to specific events on an object – insert, update, delete, or undelete. They fire before or after the event.

Use triggers when:

• Flow can’t handle the logic (complex calculations, external callouts)
• You need to perform DML on related objects
• You’re integrating with external systems
• You need immediate, synchronous processing

Use Flow when:

• Logic is straightforward and non-technical staff might maintain it
• You’re avoiding DML operations
• The logic doesn’t require external callouts (or newer Flow versions that support some callouts)
• You prefer declarative, no-code solutions

Most Salesforce teams now recommend Flow-first approaches. Triggers should be your last resort for complex logic.

9. What Is Bulkification, and Why Is It Critical?

Salesforce processes records in batches – typically 1 to 200 records at a time. Your code must handle all of them efficiently.

Non-bulkified code (bad):

trigger AccountTrigger on Account (after insert) {
    for (Account acc : Trigger.new) {
        List<Contact> contacts = [SELECT Id FROM Contact 
                                  WHERE AccountId = :acc.Id];
        // Query runs for EVERY record - could be 200 times!
    }
}

Bulkified code (good):

trigger AccountTrigger on Account (after insert) {
    Set<Id> accountIds = new Set<Id>();
    for (Account acc : Trigger.new) {
        accountIds.add(acc.Id);
    }
    
    Map<Id, List<Contact>> contactsByAccount = new Map<Id, List<Contact>>();
    for (Contact con : [SELECT Id, AccountId FROM Contact 
                       WHERE AccountId IN :accountIds]) {
        if (!contactsByAccount.containsKey(con.AccountId)) {
            contactsByAccount.put(con.AccountId, new List<Contact>());
        }
        contactsByAccount.get(con.AccountId).add(con);
    }
}

The bulkified version queries once, regardless of batch size. This respects governor limits and performs exponentially better.

10. What Is the Order of Execution, and Why Does It Matter?

When a record is saved, Salesforce executes operations in a specific sequence:

1. Original record loads from database
2. System validation checks
3. Before triggers fire
4. Validation rules execute
5. Record saves to database
6. After triggers fire
7. Assignment rules and auto-response rules execute
8. Workflow rules trigger
9. Roll-up summary fields update on parents
10. Criteria-based sharing evaluates

This matters because after triggers can’t perform DML on setup objects, and you might build circular logic if you’re not careful. Understanding the sequence prevents bugs and helps you place your automation in the right spot.

Part 5: Asynchronous Apex

11. What Are the Different Ways to Execute Async Apex, and When Do You Use Each?

Asynchronous Apex lets code run later without the user waiting.

@future Methods: Fire-and-forget functionality. Good for simple operations or external callouts. Limited to primitive data types (can’t pass sObjects directly).

@future(callout=true)

public static void callExternalService(String param) {
    // Runs asynchronously with callout capability
}

• Batch Apex: Process millions of records asynchronously. Each batch gets fresh governor limits. Ideal for data cleansing, migration, or archiving. Implement Database.Batchable<sObject>.
• Queueable Apex: More powerful than future methods. Accepts complex data types (sObjects, lists). Allows job chaining. Use when you need control over job execution and monitoring.
• Schedulable Apex: Run at specific times using cron expressions. Schedule jobs for 2 AM daily maintenance or weekly reports.

12. Explain Batch Apex with a Real Example – Start, Execute, Finish

Batch Apex breaks large jobs into smaller chunks, each with fresh governor limits.

global class UpdateAccountBatch implements Database.Batchable<sObject> {
    global Database.QueryLocator start(Database.BatchableContext bc) {
        return Database.getQueryLocator(
            'SELECT Id, Annual_Revenue__c FROM Account WHERE Active__c = true'
        );
    }
    
    global void execute(Database.BatchableContext bc, List<Account> scope) {
        for (Account acc : scope) {
            acc.Annual_Revenue__c = acc.Annual_Revenue__c * 1.1; // 10% increase
        }
        update scope;
    }
    
    global void finish(Database.BatchableContext bc) {
        System.debug('Batch processing complete');
        // Send completion email or log results
    }
}

// Execute it: Database.executeBatch(new UpdateAccountBatch(), 200);

• Start method: Determines which records to process. Returns a Database.QueryLocator.
• Execute method: Processes batches (default 200 records per batch). Each execution is its own transaction with fresh governor limits.
• Finish method: Runs after all batches complete. Perfect for sending completion emails or logging summaries.

13. What’s the Difference Between Database.Stateful and Stateless Batch Jobs?

Stateless (default): Each batch execution starts fresh. Instance and static variables reset. Good for independent operations.Stateful (implements Database.Stateful): Instance variables retain their values across batch executions. Static variables still reset. Used when you need to accumulate values across batches – like tracking total records processed or errors encountered.

global class CountingBatch implements Database.Batchable<sObject>, Database.Stateful {
    global Integer recordsProcessed = 0;
    
    // ... start, execute methods ...
    
    global void finish(Database.BatchableContext bc) {
        System.debug('Total records processed: ' + recordsProcessed);
        // This counter persists across all batch executions
    }
}

Part 6: Lightning Web Components (LWC)

14. LWC lifecycle hooks let you tap into specific moments in a component’s existence.

• Constructor: First method called when the component is created. You can’t access DOM elements here. Use it only for initializing internal variables.
• ConnectedCallback: Called when the component is inserted into the DOM. Safe place to fetch data from Apex or initialize services. Parent components render first, then children.
• Render: Conditionally returns which template to display. Useful for switching layouts based on component state.
• RenderedCallback: Called after every render. Perfect for DOM manipulation or initializing third-party libraries. BUT – it fires often, so add conditional logic to avoid loops.
• DisconnectedCallback: Called when the component is removed from the DOM. Clean up event listeners, timers, and subscriptions here to prevent memory leaks.
• ErrorCallback: Catches errors thrown within the component and prevents the entire component tree from breaking.
• Execution order (with parent and child): Parent constructor → Parent connectedCallback → Child constructor → Child connectedCallback → Parent render → Child render → Parent renderedCallback → Child renderedCallback

15. How Do You Call Apex Methods From LWC? What Are the Differences Between Wire and Imperative Calls?

Wire Decorator (recommended for reads):

import { wire } from 'lwc';
import getAccounts from '@salesforce/apex/AccountController.getAccounts';

export default class AccountList extends LightningElement {
    @wire(getAccounts, { searchTerm: '$searchInput' })
    accounts;
}

Advantages: Data automatically refreshes when dependencies change. Caches results. Perfect for read-only operations.

Imperative Calls (recommended for complex logic):

import getAccounts from '@salesforce/apex/AccountController.getAccounts';

handleSearch() {
    getAccounts({ searchTerm: this.searchInput })
        .then(result => {
            this.accounts = result;
        })
        .catch(error => {
            console.error(error);
        });
}

Advantages: More control over when calls execute. Better for create/update/delete operations. Easier to handle errors. Can call multiple methods sequentially.

16. What Are the Differences Between LWC and Aura Components?

LWC uses standard JavaScript (ES6+), HTML, and CSS – web technologies everyone knows. Aura is a proprietary framework with custom syntax.

LWC is dramatically faster because it leverages native browser capabilities. New Salesforce development is entirely LWC. Aura is being phased out.

If you’re interviewing now in 2025, you should know LWC deeply. Aura knowledge is nice but not essential anymore.

17. How Do You Handle Component Communication in LWC? Explain

Parent-to-Child, Child-to-Parent, and Sibling CommunicationParent to Child – Pass data as properties marked with @api:

// Parent
<c-child-component input-value={dataFromParent}></c-child-component>

// Child
@api inputValue;
Child to Parent - Dispatch custom events:

// Child
handleClick() {
    const evt = new CustomEvent('itemselected', {
        detail: { selectedId: this.itemId }
    });
    this.dispatchEvent(evt);
}

// Parent
<c-child-component onitemselected={handleChildEvent}></c-child-component>
Sibling to Sibling - Use Lightning Message Service (LMS) for decoupled communication:
// Publisher
import { publish, MessageContext } from 'lightning/messageService';

publish(messageContext, SAMPLE_MESSAGE_CHANNEL, { message: 'Hello' });

// Subscriber
import { subscribe, MessageContext } from 'lightning/messageService';

subscribe(messageContext, SAMPLE_MESSAGE_CHANNEL, (message) => {
    console.log(message.detail.message);
});

Part 7: Integration & APIs

18. What Are the Main Differences Between REST API and SOAP API?

• REST API: Use for new integrations, mobile apps, real-time data access. It’s simpler to work with and requires less bandwidth.
• SOAP API: Use when you need formal contracts, guaranteed delivery, or complex enterprise security requirements. Some legacy systems still require SOAP.

19. Can You Make Callouts From Triggers? How Do You Handle Integration in Triggers?

• Direct answer: No. Triggers cannot make synchronous callouts.
• Workaround: Use asynchronous methods. Fire a trigger, queue an async job to make the callout:

trigger ContactTrigger on Contact (after insert) {
    Set<Id> contactIds = new Set<Id>();
    for (Contact c : Trigger.new) {
        contactIds.add(c.Id);
    }
    
    // Queue async job to make callout
    ContactCalloutQueueable job = new ContactCalloutQueueable(contactIds);
    System.enqueueJob(job);
}

The async job can then call external APIs using HTTP class methods.

20. What Are Named Credentials, and Why Should You Use Them?

Named Credentials securely store endpoint URLs and authentication details. Instead of hardcoding credentials in your code, you reference the named credential:

HttpRequest req = new HttpRequest();
req.setEndpoint('callout:MyNamedCredential/api/endpoint');
req.setMethod('POST');

Http http = new Http();
HttpResponse res = http.send(req);

• Advantages: Credentials are stored securely by Salesforce. You can change authentication without code changes. Encrypted and audited. Much safer than hardcoding API keys.

21. How Many Callouts Can You Make Per Transaction?

Maximum 100 callouts per transaction. This includes both HTTP callouts and web service callouts. Each callout has a 120-second timeout.

Part 8: Permissions & Deployments

22. What Are Permission Sets? How Do They Differ From Profiles?

Profiles define baseline access. Every user must have exactly one profile.

Permission Sets add additional access on top of profiles. A user can have multiple permission sets, and permissions accumulate (combine, not override).

Real scenario: A sales rep has a “Sales” profile (basic access). During Q4, you need to give them temporary access to forecasting tools. Rather than changing their profile (affecting others), assign them a “Q4 Forecasting” permission set. When Q4 ends, unassign the permission set – their access reverts.

23. What Are Change Sets, and How Do You Deploy Using Them?

Change Sets are Salesforce’s native deployment tool. You bundle customizations (classes, triggers, flows, etc.) and deploy them between org environments.

Process:

1. In the source org, create an outbound Change Set and select components
2. Upload it
3. In the target org, accept the inbound Change Set
4. Validate (runs tests to check for errors)
5. Deploy (actually applies changes)

Change Sets work well for small deployments but become cumbersome at scale. Most teams are moving toward SFDX and CI/CD pipelines.

24. What Is SFDX (Salesforce CLI), and How Does CI/CD Work in Salesforce?

SFDX (Salesforce CLI) is a command-line tool that lets developers manage Salesforce orgs and deploy code like traditional software development.

CI/CD (Continuous Integration/Continuous Deployment) automates testing and deployment:

1. Developer commits code to Git repository
2. CI tool (Jenkins, GitHub Actions) automatically runs tests
3. If tests pass, changes are deployed to staging
4. If staging validates, changes deploy to production

Basic SFDX commands:

sfdx auth:web:login                                        # Connect to org

sfdx force:project:create -n MyProject       # Create project

sfdx force:source:push                                    # Deploy local code to org

sfdx force:source:pull                                       # Get org changes locally

sfdx force:source:deploy -p path -u org      # Deploy specific components

This approach scales far better than Change Sets for teams managing complex codebases.

Part 9: Testing & Quality

25. Why Is Test Coverage Important? What Should Your Tests Cover?

Salesforce requires 75% code coverage to deploy to production. But that’s the minimum – best practice is 85-90%.

Tests ensure:

• Code works as expected
• Changes don’t break existing functionality
• Code handles edge cases
• Performance stays acceptable

Your tests should cover:

• Positive scenarios: Normal happy path execution
• Negative scenarios: Invalid inputs, error conditions
• Bulk operations: Process 200+ records to verify governor limits
• Restricted users: Test as users with limited permissions using System.runAs()
• Edge cases: Empty lists, null values, boundary conditions

Part 10: Soft Skills & Behavioral Questions

26. Tell Me About a Complex Technical Challenge You Solved

Interviewers want to hear your problem-solving approach. Structure your answer: Challenge → Analysis → Solution → Results.

Example: “I was asked to sync 5 million customer records between Salesforce and a legacy ERP system nightly without impacting performance. I analyzed the constraints, realized synchronous processing would timeout, so I architected a Batch Apex solution that processed records in chunks with database rollback capabilities and error logging. Results: successful sync every night, zero data loss, team adoption increased by 40%.”

27. Describe a Time You Debugged a Difficult Issue

Highlight your systematic approach:

1. Reproduced the issue
2. Examined logs and stack traces
3. Isolated the root cause
4. Implemented a fix
5. Verified the solution

“A user reported contacts weren’t syncing with an external CRM. I checked debug logs, found that a trigger was hitting governor limits on certain record types. I optimized the bulkification, added better error handling, and communicated results to the user within 2 hours.”

28. How Do You Stay Current With Salesforce Changes?

“I regularly review Salesforce release notes each quarter, follow Apex Hours and Salesforce blogs, participate in community forums, and dedicate time to sandbox experimentation with new features.”

29. Tell Me About a Time You Worked in a Team. Any Conflicts?

“I worked on a project where I disagreed with a peer’s approach to data architecture. Rather than escalate, I documented my concerns, suggested alternatives, and we compromised on a solution that incorporated both perspectives. The project succeeded, and we both learned from each other.”

Part 11: Real Interview Scenarios & Common Mistakes

30. Scenario: You Need to Update 1 Million Records. How Do You Approach This?

Good answer: “I’d use Batch Apex. I’d write a batch class to process records in chunks (200 at a time), allowing each batch its own governor limits. I’d implement Database.Stateful if I need to track progress. I’d add comprehensive error handling and logging. I’d test thoroughly in a sandbox before scheduling in production. I’d monitor the job using the Scheduled Jobs dashboard.”

31. Scenario: Your Trigger Is Hitting Governor Limits. How Do You Debug and Fix It?

Good answer: “I’d enable debug logging to track execution. I’d use Limits class methods to see which limits are being exceeded. Common issues are queries and DML inside loops. I’d bulkify by collecting IDs in a set, querying once outside the loop, and using maps to reduce complexity. I’d also consider whether Flow could replace the trigger.”

32. Common Mistakes Developers Make

• Not bulkifying code – Causes governor limit errors
• Hardcoding IDs – Breaks in other environments
• Ignoring security – System mode bypasses all security
• Writing untestable code – Tight coupling makes testing impossible
• Not handling exceptions – Silent failures confuse users
• Recursive triggers – Same trigger fires when record is updated by the trigger
• Not considering asynchronous patterns – Synchronous code hitting limits when async would work

Part 12: Advanced Admin & Architecture Interview Questions

1. Explain the difference between OWD, Role Hierarchy, Sharing Rules, and Manual Sharing.

All four are layers in Salesforce’s record-level security model. They always work in this order: start restrictive, then open up access. You never reduce access with these; you only expand it.

• OWD (Organization-Wide Defaults)
  This is the baseline. It defines the default access level for records of an object for everyone in the org: Private, Public Read Only, Public Read/Write, or Controlled by Parent. If OWD is Private, nobody can see another user’s records unless one of the other mechanisms grants access.​
• Role Hierarchy
  Think of this as “up-the-chain” visibility. Users higher in the role hierarchy automatically gain visibility to records owned by users in roles below them (assuming “Grant Access Using Hierarchies” is enabled for that object). It mirrors your org chart and is vertical access, not lateral.​
• Sharing Rules
  These are automatic exceptions to OWD (and role hierarchy). They are used to share sets of records with users or groups who don’t already have access. Two common types:
  • Owner-based: share records owned by certain roles/public groups with other roles/groups.
  • Criteria-based: share records where certain field criteria are met (e.g., Region = “EMEA”).
    Sharing rules are great for lateral sharing between teams at the same level.​
• Manual Sharing
  This is record-by-record sharing. A record owner (or someone with Full Access/admin) can manually share a specific record with another user or group when no rule-based mechanism applies. It’s perfect for one-off collaboration scenarios rather than patterns you can model with rules.​

In short: OWD sets the floor, role hierarchy opens access up the chain, sharing rules open access sideways at scale, and manual sharing handles one-off edge cases.

2. What is Data Skew and how do you prevent it?

Data skew happens when a very large number of records are tied to a single parent or owner. It typically shows up in two forms:

• Ownership Skew – Too many records (often hundreds of thousands) owned by a single user or queue.
• Lookup/Parent Skew – Too many child records pointing to the same parent via a lookup or master-detail field.​

Why it’s bad:

• Record locking and “UNABLE_TO_LOCK_ROW” errors during bulk updates
• Slow queries and timeouts
• Higher risk of hitting governor limits
• Poor user experience due to slow pages and reports​

Prevention/mitigation strategies:

• Distribute ownership across multiple users or queues; don’t let one integration user own millions of records.​
• Avoid funneling tens of thousands of children to a single parent record; redesign the data model (e.g., additional hierarchy levels, denormalization).​
• Use public groups and sharing rules instead of 1 “catch-all” owner to provide access.​
• Archive or offload old records (to Big Objects, external storage, or external systems) so the active data set stays lean.​
• Optimize queries (selective filters, indexes, skinny tables for extreme LDV) so even skewed data doesn’t cripple performance.​

3. What is the difference between Record-Triggered Flow (Before vs After)?

Record-triggered flows can run before or after the record is saved. The choice directly affects performance and capabilities.​

• Before-Save (Fast Field Updates)
  • Runs before the record is committed to the database.
  • Best when you only need to update fields on the triggering record itself.
  • Extremely fast (in-memory update), similar to a before trigger.
  • Cannot perform DML on other records or send emails.
  • Typical use cases: auto-populating fields, normalizing values, stamping default values.​
• After-Save (Actions and Related Records)
  • Runs after the record has been saved.
  • Can perform DML on other records, send emails, call subflows, and publish platform events.
  • Slightly slower, but much more powerful.
  • Typical use cases: creating related records, updating parent/child records, making callouts (via invocable Apex) after commit, complex business processes.​

Rule of thumb:
If you’re only touching the triggering record’s fields, use before-save. If you need to touch other records or perform actions, use after-save.

4. How do you handle Flow errors in production?

In production, you want to capture errors, notify the right people, and avoid exposing raw Salesforce errors to end users.

Good patterns include:

• Fault paths everywhere:
  Add fault connectors from elements that can fail (DML, subflows, callouts) to dedicated error-handling paths. Log the error message and context (record Id, user, flow name).​
• Centralized error-handling subflow:
  Build a reusable subflow that:
  • Creates an “Error Log” custom object record
  • Stores Flow Name, Element, Error Message, User, and Record Id
  • Optionally sends an email or notifies a Slack/Teams channel
• User-friendly error screens (for screen flows):
  Catch errors and display a clear, non-technical message (“Something went wrong while saving. Your admin has been notified.”), while logging details server-side.
• Platform event or email alerts:
  For critical automations, send alerts to admins/DevOps when fault paths are hit, so they can react quickly.
• Use debug logs & Flow error emails:
  Make sure “Send Process or Flow Error Email To” is configured, and use debug logs to reproduce and fix issues.

5. What is the best use case for Scheduled Flow?

Scheduled flows are ideal when you need time-based automation over a set of records without writing Apex.

Good use cases:

• Nightly processes: recalculate scores, flag stale opportunities, send reminders.
• Data hygiene: mark records inactive after a certain date, archive flags, follow-up tasks.
• Back-office operations: scheduled updates based on date fields (e.g., contracts expiring in 30 days).

They’re not record-triggered; instead, they run on a schedule and query batches of records via a Get Records, then loop through them. Use them when timing is “run every X hours/days” rather than “when this record changes”.

6. Explain Dynamic Forms and how they are different from Page Layouts.

Dynamic Forms move field and section management from the page layout into the Lightning App Builder, giving you much more control.

Differences:

• Per-field visibility: With Dynamic Forms you can show/hide individual fields or sections based on record values, user, device, etc. Page Layouts only give you layout-level assignments per profile/record type.
• Performance: Only the fields on the visible Dynamic Form section are loaded, which can improve page load performance on very heavy layouts.
• Granular control: You can rearrange, group, and conditionally display fields at the Lightning page level without cloning multiple page layouts.
• Future direction: Salesforce is investing in Dynamic Forms as the long-term model; page layouts are still there but primarily as a base.

In short: Page layouts are coarse-grained and profile/record-type driven; Dynamic Forms are fine-grained and condition-driven at the Lightning page level.

7. What are Dynamic Related Lists?

Dynamic Related Lists are a Lightning App Builder component (Dynamic Related List – Single) that let you configure and filter related lists directly on the Lightning page, instead of being tied to a page layout.​​

Key capabilities:

• Custom filters: Show only certain related records (e.g., only Open Opportunities, only High-priority Cases).
• Custom sort: Sort by any field (Created Date, Priority, Amount, etc.).
• Field selection: Choose which columns appear in the related list, independent of the page layout.
• Multiple instances: Add multiple related lists for the same child object on the same page, each with different filters (e.g., “Open Opportunities” and “Closed Won Opportunities”).​​

They give admins far more flexibility to surface just the relevant related records for each business scenario.

8. What are Duplicate Rules and how do they work with Matching Rules?

Think of it this way:

• Matching Rules = How to detect potential duplicates
• Duplicate Rules = What to do when a potential duplicate is found​​

Matching Rules define the logic for comparing records:

• Which fields to compare (Email, Phone, Company, etc.)
• Exact vs fuzzy matching (to catch typos and variations)​

Duplicate Rules use one or more matching rules to:

• Decide when to run (on create, on edit, or both)
• Decide what happens:
  • Block saving the record
  • Allow but alert the user and show possible duplicates
  • Allow silently but log the duplicate​​

Together:

• Matching Rules identify possible dupes
• Duplicate Rules enforce your business policy (block vs warn vs log)

9. How would you migrate metadata from one sandbox to another?

A strong answer should mention multiple options, not just change sets:

• Change Sets
  • Native, click-based Salesforce tool for moving metadata between related orgs (e.g., dev sandbox → QA → prod).
  • Good for smaller teams and simple deployments, but manual and harder to track.​
• Salesforce DevOps Center
  • Salesforce’s modern DevOps solution that uses version control and work items.
  • Better change tracking than change sets; fits teams willing to adopt Git and a pipeline.​
• SFDX / Salesforce CLI (Source-Driven Development)
  • Use sfdx force:source:retrieve and force:source:deploy (or project:deploy) to move metadata as files.
  • Ideal for CI/CD and version-controlled workflows.
• ANT Migration Tool
  • XML/script-based deployments using build.xml and package.xml.
  • Still used in legacy CI scripts, but SFDX is the modern alternative.

In interviews, show you know all of these and can pick based on team maturity and complexity.

10. What is the difference between Change Set and DevOps Center?

Both move metadata, but they represent two different eras.​

Change Sets:

• Point-and-click, org-to-org deployments only (must be related to the same production).
• No version control, no change tracking, no destructive changes (you can’t deploy deletions).
• Suitable for small teams and simple orgs, but manual and error-prone.​

DevOps Center:

• Introduces Git-based version control as the source of truth.
• Tracks changes in work items, supports branching and PR-based workflows.
• Supports destructive changes so you can safely test deletions in lower environments.​
• Encourages formal pipelines (dev → test → UAT → prod) rather than ad-hoc org-to-org pushes.​

In short: Change Sets are basic, manual org-to-org deployments; DevOps Center is Salesforce’s native step toward real DevOps with version control and structured pipelines.

11. What is a Joined Report and when should you use it?

A Joined Report lets you combine multiple report blocks, each with its own report type, into a single report view.

Key characteristics:

• Each block can have different fields, filters, and even different report types (e.g., Opportunities with Products and Cases).[Salesforce docs, common knowledge]
• You can group by a common field across blocks (like Account) to see related data side by side.
• Useful for comparative analysis where a single standard report type cannot show everything in one place.

Use cases:

• Show Accounts with both Opportunities and Cases in one report.
• Compare pipeline vs actual revenue side by side.
• Combine multiple objects that don’t share a single standard/custom report type.

12. What are Queue-based assignments?

Queues are like virtual “buckets” of records that a team owns collectively instead of a single user.​

Key points:

• You can assign records to a queue by setting the Owner to that queue.
• Assignment rules (Lead or Case) can automatically route new records to the appropriate queue based on criteria (region, product line, priority).​
• Users who are members of the queue can then “take ownership” of records from it.
• Great for shared workloads (support teams, SDR teams) and round-robin/manual pull models.

So queue-based assignment means your automation (assignment rules, flows) is routing records to queues, not individual users, and users pick them up from there.

13. How do you troubleshoot workflow/flow not running issues?

A strong debugging approach:

1. Check activation:
   • Is the latest version of the flow/process active?
   • Is there more than one automation competing on the same object/event?
2. Verify entry criteria:
   • Do the record values actually meet the start conditions?
   • Remember: “Only when record is updated to meet the condition” means the condition must change from false → true to fire.​
3. Order of execution conflicts:
   • Other automations (validation rules, triggers) may block DML, so your flow never sees the final state.
   • Check if errors occur before your flow step in debug logs.
4. Check “Run As” user and permissions:
   • For flows, if the running user doesn’t have access (CRUD/FLS), operations may fail silently or fault.
5. Debug logs & Flow error emails:
   • Turn on debug logs for the user and reproduce.
   • Review Flow error emails for unhandled exceptions.
6. Test in debug mode (for flows):
   • Use Flow Debug with sample records in a sandbox to confirm path execution.

14. What is Field Tracking History? Limitations?

Field History Tracking lets you track changes to selected fields on an object (old value, new value, who changed it, and when). It’s great for auditing and compliance.​

Key limitations:

• Limit of 20 fields per object by default (per standard/custom object, excluding Activities).​
• For Task/Event (Activities), only 6 fields can be tracked per object.​
• History is typically retained for up to 18 months in the org, though you can access older via API/Export All but it’s not guaranteed.​
• To go beyond 20 fields and longer retention, you need Field Audit Trail (paid add-on), which can track up to 60 fields per object and store history longer.​

History data is stored in ObjectNameHistory tables and doesn’t count against your standard data storage but does consume special history storage.

15. What are Field-Level Security, Page Layouts, and Record Types – and how do they work together?

These three work at different layers:

• Field-Level Security (FLS) – “Can I see or edit this field at all?”
  • Controlled via profiles/permission sets.
  • Determines whether a field is visible or read-only for a user, regardless of layout.
  • If FLS says hidden, the field is invisible everywhere, even if it’s on a page layout.
• Page Layouts – “Where does this field appear on the page, and is it required/read-only in the UI?”
  • Control section grouping, related lists, and UI-level required/read-only settings.
  • Limited by FLS: a field hidden by FLS won’t show even if included on the layout.
• Record Types – “Which layout and picklist values apply to this record?”
  • Let you present different page layouts and picklist value sets based on the record’s type and the user’s profile.
  • Example: “B2B Account” vs “B2C Account” with different required fields/layouts.

Together:

1. FLS decides if you can see/edit a field.
2. Record Types decide which layout and picklist values you get.
3. Page Layouts decide where the field shows and its UI behavior.

16. How do Sharing Sets work for Experience Cloud users?

Sharing Sets are designed specifically for Experience Cloud (community) users to grant them access to records tied to their own Account or Contact.​

Key points:

• Sharing Sets use access mappings:
  • From the user (e.g., User.Contact.AccountId)
  • To the target object’s lookup (e.g., Case.AccountId)​
• Common example: “Give a portal user access to all Cases where the Case’s Account equals the user’s Account.”
• They apply per profile (you choose which Experience Cloud profiles a sharing set applies to).​
• They don’t follow role hierarchy; they’re specific to the user’s own relationship.​

In short, Sharing Sets say: “If a record’s account/contact matches the logged-in Experience user’s account/contact, grant them access.”

17. What is the difference between Email-to-Case and On-Demand Email-to-Case?

Both automatically convert incoming emails into Cases, but they differ in architecture and limits.​

Email-to-Case (Agent-Based):

• Requires an Email-to-Case agent installed behind your corporate firewall.
• Can handle emails larger than 25 MB (attachments + body).​
• Does not consume API calls for case creation.​
• More control over routing within your network but needs infrastructure.

On-Demand Email-to-Case:

• Cloud-only, no agent required; Salesforce processes the emails directly.​
• Rejects emails > 25 MB.​
• Uses Apex email services and does contribute to API usage.​
• Easier and faster to set up, good for most orgs whose email sizes are modest.

In practice, many orgs rely purely on On-Demand Email-to-Case unless they have specific on-premise or large-attachment requirements.

18. What is a Skinny Table?

A Skinny Table is a database-level table that Salesforce Support can create behind the scenes to improve performance on objects with large data volumes by denormalizing frequently-used fields into a single table.​

Key facts and limitations:​

• Can contain up to 100 columns.
• Can only include fields from one object (no cross-object fields).
• Is read-optimized, mainly for SELECT queries (not a magic fix for bad design).
• Is not automatically copied to sandboxes; you must ask Salesforce to create skinny tables there too.​
• Kept in sync with the base object automatically by the platform.​

They are typically considered only after you’ve already optimized queries, indexes, and data model for large data volumes.

19. How do you improve Salesforce performance for large data volumes?

Improving performance with Large Data Volumes (LDV) is mostly about data model, indexing, and query selectivity, plus avoiding skew.​

Best practices:

• Design for LDV from day one:
  • Avoid data skew (ownership and lookup).
  • Use proper parent–child relationships and archiving strategies.​
• Use selective queries and indexes:
  • Filter on indexed fields (Id, foreign keys, external IDs, custom indexes).
  • Keep filters selective:
    • Standard index: ideally match <30% of rows (up to 1M).​
    • Custom index: ideally match <10% of rows (max 333,333 records).​
  • Avoid LIKE ‘%text%’ and IS NULL filters when possible.​
• Archive old data:
  • Move inactive/legacy records to Big Objects, external systems, or separate archive objects.
  • Keep the “hot” data set small.
• Use asynchronous processing:
  • Batch Apex, Queueables, and Scheduled jobs for heavy operations instead of synchronous triggers.​
• Consider skinny tables where appropriate:
  • For extremely heavy read patterns on a few fields, Salesforce Support can create skinny tables to avoid joins.​

Overall, LDV performance is about good modeling, selective queries, controlled sharing, and thoughtful automation.

20. What is Territory Management (high-level)?

Territory Management (specifically Enterprise Territory Management) is a Salesforce feature that lets you assign Accounts (and optionally Opportunities/Cases) to sales territories based on rules, instead of just roles or owners.

High-level concepts:

• Territories: Logical groupings like “North America – Enterprise”, “EMEA – SMB”, “Healthcare – West”.
• Territory Models: Let you design and test a territory hierarchy before activating it.
• Territory Assignment Rules: Evaluate Account attributes (industry, region, size) to assign Accounts into territories.
• Access Control: Territory membership gives users access to Accounts/opportunities in that territory, independent of role hierarchy.

It’s fundamentally about aligning data access and reporting with how your sales org is structured in the real world (regions, segments, industries), not just who owns the record.

Final Interview Preparation Tips

1. Understand the Why – Know not just what but why concepts work this way
2. Practice Coding – Actually write Apex and JavaScript in a developer org, not just read about them
3. Know Your Project Examples – Have real examples of what you’ve built
4. Ask Clarifying Questions – Vague questions deserve clarification, not assumptions
5. Think About Trade-offs – Different approaches have different pros and cons
6. Stay Updated – Salesforce releases quarterly; stay aware of new features
7. Be Honest – Admitting knowledge gaps is better than guessing incorrectly

Conclusion

Preparing for a Salesforce developer interview means building genuine understanding of the platform’s architecture, best practices, and real-world application. The questions and scenarios in this guide represent what you’ll actually encounter. Focus on comprehension over memorization, practice writing real code, and be ready to discuss your problem-solving approach with confidence. You’ve got this.