As organizations rely on Salesforce to automate workflows, manage customer relationships, and scale business operations, recruiters must identify Salesforce Developers who can build secure, efficient, and customized solutions on the Salesforce platform. With expertise in Apex, Lightning Web Components (LWC), integrations, and declarative configurations, these developers power modern CRM-driven digital experiences.
This resource, "100+ Salesforce Developer Interview Questions and Answers," is tailored for recruiters to simplify the evaluation process. It covers a wide range of topics—from Salesforce fundamentals to advanced development, including Apex triggers, governor limits, LWC development, and API integrations.
Whether you're hiring Salesforce Developers, Lightning Developers, or Salesforce Platform Engineers, this guide enables you to assess a candidate’s:
- Core Salesforce Knowledge: Org setup, data model, objects, relationships, validation rules, workflows, and security model.
- Advanced Skills: Apex classes and triggers, SOQL/SOSL queries, Lightning Web Components, asynchronous Apex (Queueables, Batch, Future), and platform events.
- Real-World Proficiency: Building scalable components, integrating external systems using REST/SOAP APIs, optimizing for governor limits, and deploying changes using Salesforce DevOps tools.
For a streamlined assessment process, consider platforms like WeCP, which allow you to:
- Create customized Salesforce Developer assessments for Apex, LWC, integrations, or platform-specific development.
- Include hands-on tasks such as writing Apex triggers, debugging SOQL queries, or building Lightning components.
- Proctor exams remotely while ensuring integrity.
- Evaluate results with AI-driven analysis for faster, more accurate decision-making.
Save time, enhance your hiring process, and confidently hire Salesforce Developers who can build scalable, efficient, and enterprise-ready CRM solutions from day one.
Salesforce developer Interview Questions
Salesforce developer – Beginner (1–40)
- What is Salesforce and what problems does it solve?
- What is the difference between Salesforce Administrator and Salesforce Developer?
- What are Standard Objects in Salesforce?
- What are Custom Objects?
- What is an App in Salesforce?
- What is a Tab in Salesforce?
- What is a Record in Salesforce?
- What is a Field in Salesforce?
- What are Validation Rules?
- What is a Workflow Rule?
- What is the difference between Workflow and Process Builder?
- What is Apex?
- What is a Trigger in Salesforce?
- What are the different trigger events?
- What is SOQL?
- What is SOSL?
- Difference between SOQL vs SOSL?
- What are Governor Limits in Salesforce?
- Why does Salesforce have Governor Limits?
- What is a Sandbox?
- Types of Sandboxes in Salesforce?
- What is a Profile?
- What is a Permission Set?
- What is a Role in Salesforce?
- What is the difference between Role and Profile?
- What are Sharing Rules?
- What is OWD (Organization-Wide Defaults)?
- What are Page Layouts?
- What are Record Types?
- What is Lightning Experience?
- What is LWC (Lightning Web Components)?
- What is Aura Component?
- What is Lightning App Builder?
- What is a Static Resource?
- What is Apex Class?
- What is Test Class in Salesforce?
- What is Data Loader?
- What is the difference between Data Import Wizard and Data Loader?
- What is the Recycle Bin in Salesforce?
- What is the significance of 75% code coverage in Salesforce?
Salesforce developer – Intermediate (1–40)
- Explain the order of execution in Salesforce.
- What is a Trigger Context Variable?
- What is Bulkification and why is it important?
- How do you prevent recursive triggers?
- What is a Trigger Handler Framework?
- Explain different types of Apex Collections.
- What is a Wrapper Class?
- What is the difference between List, Set, and Map?
- How do you handle exceptions in Apex?
- What are Custom Metadata Types?
- Difference between Custom Metadata and Custom Settings?
- What is a Future Method?
- What is Queueable Apex?
- Difference between Batch Apex and Queueable?
- What is Scheduled Apex?
- What are Lightning Events in Aura?
- What is LDS (Lightning Data Service)?
- Explain Component Lifecycle for LWC.
- What is @wire decorator in LWC?
- How do you call Apex from LWC?
- What is the difference between imperative and wired Apex calls?
- What is Lightning Message Service (LMS)?
- What is AuraEnabled annotation?
- What is API Versioning in Salesforce?
- What is a Connected App?
- What is the use of Named Credentials?
- How do you integrate Salesforce with REST API?
- How do you integrate Salesforce with SOAP API?
- What is Platform Events?
- What is Change Data Capture (CDC)?
- What is Shield Encryption?
- How do you handle large data volumes (LDV) in Salesforce?
- What is Skinny Table?
- What are Salesforce Governor Limits for SOQL, DML, heap, etc.?
- What is the difference between synchronous and asynchronous Apex?
- What is Deployment using Change Sets?
- What is deployment using Metadata API / CI/CD?
- How do you use ANT Migration Tool?
- What is the difference between a Permission Set and Permission Set Group?
- What security considerations should a developer follow in Salesforce?
Salesforce developer – Experienced (1–40)
- Explain the full internal request lifecycle of a Salesforce transaction.
- What are different Apex design patterns used in Salesforce?
- Explain Unit of Work (UOW) pattern in detail.
- What is Enterprise Integration Patterns (EIP)?
- How do you scale Apex for millions of records?
- How do you design multilevel, enterprise-grade trigger frameworks?
- Explain the architecture differences between Aura and LWC.
- How do you optimize SOQL queries?
- How do you handle "Too Many SOQL Queries" exceptions in large batch processing?
- Explain best practices to handle callouts in batch classes.
- How do you implement custom logging frameworks in Salesforce?
- How do you design complex approval automations using Flow + Apex?
- How do you debug governor limit issues in production?
- What are key security vulnerabilities developers must avoid?
- How do you prevent SOQL injection in Apex?
- Explain how to design high-performance LWCs.
- What caching mechanisms are available in Salesforce?
- How do you implement Platform Cache effectively?
- How do you use Integration Patterns: Remote Process Invocation, Batch Data Sync, etc.?
- How do you ensure reliable asynchronous processing with Queueable + Platform Events?
- What architectural approaches do you use for enterprise-level integrations?
- What is the difference between Platform Events vs CDC vs Outbound Messaging?
- How do you manage distributed transactions in integrations?
- What is External Objects & Salesforce Connect?
- When do you choose Heroku vs Salesforce native solutions?
- Explain the security model when integrating with external systems.
- How do you build CI/CD pipelines for Salesforce using GitHub Actions / Azure / Jenkins?
- What is unlocked packaging and when to use it?
- How do you architect multi-org Salesforce systems?
- What problems arise with LDV (Large Data Volume) and how to overcome them?
- How do you optimize LWC rendering performance?
- What is Apex Continuation?
- How do you debug complex Lightning component issues?
- How do you design audit and compliance frameworks in Salesforce?
- Explain asynchronous chaining patterns in Salesforce.
- How do you implement fault-tolerant integration?
- What patterns do you use for high-availability system design in Salesforce?
- Explain the best approaches to handle recursive flows.
- What is Transaction Finalizer?
- What are advanced Spring ’24 / Summer ’24 Salesforce enhancements developers should know?
Salesforce developer Interview Questions and Answers
Beginner (Q&A)
1. What is Salesforce and what problems does it solve?
Salesforce is a cloud-based Customer Relationship Management (CRM) platform that enables businesses to manage their customers, sales processes, services, marketing, and operations using a single integrated system. It operates entirely on the cloud, meaning organizations don’t need to install hardware, maintain servers, or build complex infrastructure. Salesforce provides prebuilt business applications and tools that can be customized for any industry—finance, healthcare, retail, manufacturing, and more.
Salesforce solves several major business problems:
- Fragmented customer data
Many companies store data across multiple systems. Salesforce centralizes all customer information—contacts, sales deals, support history, marketing campaigns—into one unified platform. - Inefficient sales processes
Sales teams often struggle to track leads, opportunities, and follow-ups. Salesforce automates these tasks so teams can work faster and close more deals. - Lack of real-time business insights
Salesforce offers dashboards, reports, and AI-powered predictions so companies can make data-driven decisions instantly. - Difficult collaboration across teams
With Salesforce, sales, support, and marketing teams collaborate on one platform and have visibility into customer interactions. - High cost and complexity of traditional CRMs
Because Salesforce is cloud-based, it reduces the cost of maintaining hardware or hiring large IT teams. Updates roll out automatically. - Scalability problems
Salesforce grows with the business—whether a company has 5 users or 5,000.
In short, Salesforce helps businesses work smarter by streamlining processes, improving customer relationships, and enabling fast innovation without heavy technical overhead.
2. What is the difference between Salesforce Administrator and Salesforce Developer?
A Salesforce Administrator and a Salesforce Developer are two critical roles in the Salesforce ecosystem, but both serve different purposes.
Salesforce Administrator
An admin focuses on managing, configuring, and maintaining the Salesforce platform without writing code. Their work ensures users can effectively use the system.
Key responsibilities:
- Creating and managing users, roles, and profiles
- Setting up permissions and security controls
- Configuring objects, fields, page layouts
- Creating validation rules, flows, process builder automations
- Running reports and dashboards
- Managing data imports/exports
- Handling day-to-day support and troubleshooting
Admins are considered “business problem solvers” who use Salesforce’s declarative (no-code) tools.
Salesforce Developer
A developer focuses on building custom features and extending the platform using programming.
Key responsibilities:
- Writing Apex classes and triggers
- Building Lightning Web Components (LWC)
- Integrating Salesforce with external systems via APIs
- Creating advanced automation logic not possible through clicks
- Optimizing performance and scalability
- Writing test classes and maintaining code coverage
Developers handle more complex requirements that exceed Salesforce’s built-in capabilities.
In summary:
RoleSkill TypePrimary ToolsFocusAdminNo-codeFlows, Process Builder, Page Layouts, PermissionsConfiguration & user supportDeveloperCodeApex, LWC, SOQL, IntegrationsCustomization & complex automation
Both roles collaborate closely to build powerful, scalable systems.
3. What are Standard Objects in Salesforce?
Standard Objects are predefined objects provided out-of-the-box by Salesforce. These objects come with built-in fields, relationships, and functionality that support common business processes like sales, service, and marketing.
Some of the most used Standard Objects include:
- Account – Represents a company or organization.
- Contact – Represents an individual person associated with an Account.
- Lead – Represents a potential customer or business prospect.
- Opportunity – Represents a sales deal in progress.
- Case – Used for customer support and service issues.
- Campaign – Used for marketing programs and outreach.
- User – Represents a person with login access to Salesforce.
Why Standard Objects are important:
- They provide ready-to-use CRM functionality.
- They are automatically optimized for reporting, sharing, and security.
- They integrate with Salesforce automation and declarative tools.
- They reduce development time, since many common business entities are already available.
Standard Objects form the foundation of Salesforce’s data model.
4. What are Custom Objects?
Custom Objects are user-created objects that extend the Salesforce data model to meet specific business needs not covered by Standard Objects.
For example, a business may need to track:
- Job applications
- Shipments
- Contracts
- Projects
- Student records
- Equipment inventory
These use cases may not fit Standard Objects, so Custom Objects allow organizations to build their own database tables.
Features of Custom Objects:
- Fully customizable fields
- Custom page layouts and record types
- Custom tabs
- Relationship fields (Lookup/Master-Detail)
- Built-in audit and sharing features
- Support for workflows, flows, Apex triggers, and reports
- API access like any standard object
Custom Objects make Salesforce extremely flexible and suitable for virtually any business model.
5. What is an App in Salesforce?
In Salesforce, an App is a collection of tabs, objects, and functionality grouped together to serve a specific purpose. It functions as a container that helps users access all related tools and data in one place.
There are two main types of Apps:
- Classic Apps – Used in Salesforce Classic, based on tabs.
- Lightning Apps – Used in Lightning Experience with modern UI features.
An App typically includes:
- Standard and custom object tabs
- Navigation items
- Branding (logo and theme)
- Lighting pages
- Utility items (like Notes, History, etc.)
Examples of Apps:
- Sales App
- Service Console
- Marketing App
- Custom HR App
- Inventory Management App
Apps enhance usability by organizing features needed for a particular business function, reducing complexity for end users.
6. What is a Tab in Salesforce?
A Tab in Salesforce is a UI element that allows users to access the data and functionality of an object or feature quickly. Think of it as a shortcut or gateway to a specific object.
Types of Tabs:
- Object Tabs (Standard or Custom Objects)
- Web Tabs (Display external web pages)
- Visualforce Tabs
- Lightning Page Tabs
- Custom Tabs (For custom-built features)
Why Tabs are important:
- They make navigation intuitive
- Allow users to access records efficiently
- Organize business processes into visible sections
- Help administrators customize user experience
Tabs provide direct entry points into Salesforce’s data and workflows.
7. What is a Record in Salesforce?
A Record is a single instance or row of data stored in an object. If an object is like a database table, a record is like one entry in that table.
Example:
- Object: Account
- Record: "IBM Corporation"
For the Contact object:
Records contain data stored in fields such as Name, Email, Phone, etc.
Each record has:
- A unique ID
- Field values
- Related list data
- Ownership and sharing rules
- Audit trail information
Records represent the actual business data that users interact with on a daily basis.
8. What is a Field in Salesforce?
A Field is a specific piece of information stored within a record, similar to a column in a table. Fields define the structure of the data in an object.
Examples of Field types:
- Text
- Number
- Checkbox
- Formula
- Date / DateTime
- Picklist
- Lookup Relationship
- Master-Detail Relationship
Purpose of Fields:
- Store essential information like name, address, price, status
- Define business rules through formulas
- Support automation through workflows and flows
- Make data searchable and reportable
Fields shape how records are stored, displayed, and processed in Salesforce.
9. What are Validation Rules?
Validation Rules ensure that data entered into Salesforce meets certain criteria before it is saved. They are used to maintain data quality and enforce business policies.
A Validation Rule consists of:
- A logical formula that evaluates to TRUE or FALSE
- An error message shown if the condition is violated
Example use cases:
- Prevent closing an Opportunity without entering the Amount
- Ensure Email field contains “@”
- Block editing if a Case is “Closed”
- Prevent negative values in Quantity fields
Benefits:
- Improves data accuracy
- Prevents incomplete or incorrect submissions
- Enforces business standards automatically
Validation Rules are essential for controlling data integrity across the system.
10. What is a Workflow Rule?
A Workflow Rule is an automation tool in Salesforce that triggers actions based on conditions. Although Salesforce Flow is replacing Workflow Rules, they are still widely used in many orgs.
Workflow Rules consist of:
- Criteria – When the rule should run
- Actions – What should happen when the criteria are met
Possible Workflow Actions:
- Send Email Alerts
- Update Fields
- Create Tasks
- Send Outbound Messages
Examples:
- Send a reminder email when a Case is opened
- Auto-update Opportunity Status when Probability changes
- Assign follow-up tasks when a Lead is created
Limitations:
- No looping
- Cannot delete records
- Limited number of actions
- No complex conditions compared to Flow
Despite limitations, Workflow Rules remain a simple way to automate repetitive tasks.
11. What is the difference between Workflow and Process Builder?
Workflow and Process Builder are both declarative automation tools in Salesforce designed to automate business processes without writing code. However, they differ in capabilities, complexity, and the type of actions they support.
Workflow
Workflow is the older automation tool with limited functionality.
It supports simple, linear automation and is best used for basic actions.
Workflow supports only four types of actions:
- Field Update
- Email Alert
- Task Creation
- Outbound Message
Characteristics of Workflow:
- Can only evaluate criteria at the time of record creation or modification
- Cannot handle multiple if/else conditions
- Fires actions immediately or on a time-dependent basis
- Cannot create records (except Tasks)
- Faster and simpler, but limited
Process Builder
Process Builder is more advanced and supports complex, multi-step logic with branching.
Process Builder supports many actions:
- Create records
- Update related records
- Invoke Apex classes
- Launch Flows
- Post to Chatter
- Submit records for Approval
- Call other processes
- Send emails, tasks, notifications
Characteristics of Process Builder:
- Can evaluate multiple criteria and branches
- Can create or update multiple records
- Can handle more automation with fewer tools
- More flexible but slower compared to Workflow
Summary Comparison
FeatureWorkflowProcess BuilderActionsLimited (4 types)Many actionsComplexity supportLowHighCreate recordsOnly tasksYes, any recordUpdate related recordsNoYesCall ApexNoYesEvaluationSimpleAdvanced branchingPerformanceFasterSlower
In modern Salesforce:
✔ Workflow and Process Builder are being phased out
✔ Salesforce recommends using Flow for new automations
12. What is Apex?
Apex is a strongly typed, object-oriented programming language created by Salesforce. It is used to build custom business logic on the Salesforce platform.
Apex runs on the Salesforce server (on the Force.com platform) and allows developers to extend Salesforce beyond the capabilities of declarative tools.
Key features of Apex:
- Syntax similar to Java
- Runs on Salesforce cloud
- Supports DML operations (insert, update, delete, upsert)
- Used for triggers, classes, test classes, batch processes
- Supports asynchronous operations
- Enforces governor limits
- Fully integrated with Salesforce APIs, SOQL, and SOSL
Where Apex is used?
- Writing triggers to automate logic before or after DML
- Creating custom business logic in Apex Classes
- Calling external APIs via callouts
- Writing batch and scheduled jobs
- Developing controllers for Visualforce pages
- Backend logic for Lightning Web Components
Apex is essential for building scalable and customized enterprise-grade Salesforce applications.
13. What is a Trigger in Salesforce?
A Trigger is an Apex program that automatically executes before or after certain database operations (DML events) take place on a Salesforce object.
Triggers help automate complex logic that cannot be achieved through declarative tools like Validation Rules or Flows.
Two types of triggers:
- Before Triggers
- Modify record values before saving
- Common uses: default values, data validation, updating fields
- After Triggers
- Access record ID after saving
- Common uses: sending notifications, creating related records, making callouts
Why triggers are used?
- Enforce complex business rules
- Update or validate related records
- Perform cross-object operations
- Handle massive data operations efficiently
Triggers are powerful but should always be bulkified and designed using frameworks to avoid recursion and governor limit issues.
14. What are the different trigger events?
Trigger events represent the specific points in the data lifecycle where Apex triggers can execute.
Salesforce supports the following trigger events:
- before insert
- before update
- before delete
- after insert
- after update
- after delete
- after undelete
Explanation of each:
- before insert – Runs before a new record is saved
- before update – Runs before an existing record is modified
- before delete – Runs before a record is deleted
- after insert – Runs after a new record is saved (ID available)
- after update – Runs after a record is updated in the database
- after delete – Runs after a record is deleted
- after undelete – Runs after a record is restored from recycle bin
These events allow developers to hook custom logic at any critical point of a record’s lifecycle.
15. What is SOQL?
SOQL (Salesforce Object Query Language) is a query language used in Salesforce to retrieve records from objects. It is similar to SQL but designed specifically for Salesforce’s multi-tenant architecture.
Key characteristics of SOQL:
- Retrieves data from one or multiple objects
- Supports filtering, ordering, and grouping
- Returns data as lists of sObjects
- Supports relationship queries (parent-to-child, child-to-parent)
- Used in Apex, API calls, and Developer Console
Example SOQL Query:
SELECT Id, Name, Email FROM Contact WHERE AccountId = '001xxxx'
SOQL is optimized for Salesforce’s cloud environment and ensures efficient, secure data retrieval.
16. What is SOSL?
SOSL (Salesforce Object Search Language) is a text-based search language used to perform global searches across multiple objects.
SOSL is useful when you need to search for a keyword anywhere in Salesforce, regardless of object or field.
Key features of SOSL:
- Searches multiple objects at the same time
- Searches across text, email, phone, and other fields
- Returns results in multiple lists grouped by object
- Very fast for keyword-based searches
- Ideal for global search and lookup scenarios
Example SOSL Query:
FIND 'John*' IN ALL FIELDS RETURNING Contact(Id, Name), Account(Id, Name)
SOSL is powerful for text-based searches where object and field-specific queries are not practical.
17. Difference between SOQL vs SOSL?
SOQL and SOSL serve different purposes in Salesforce.
SOQL (Structured Query)
- Retrieves data from one object at a time
- Supports conditions, filters, and relationships
- Best for structured queries and reporting
SOSL (Search-Based Query)
- Searches across multiple objects
- Best for full-text or keyword searches
- Returns grouped results
Comparison Table
FeatureSOQLSOSLPurposeQuery structured dataSearch text across multiple objectsSearch typeRecord-based queryingKeyword-based searchingResult structureOne sObject listMultiple lists grouped by objectSpeedSlower for keyword searchFaster for keyword searchUse caseFind specific recordsGlobal search-like functionality
In short:
✔ Use SOQL for precise, structured data retrieval
✔ Use SOSL for keyword searches across many objects
18. What are Governor Limits in Salesforce?
Governor Limits are platform-enforced rules that restrict the amount of resources a single Salesforce transaction can consume. Since Salesforce is a multi-tenant cloud environment, it must ensure no single user or org consumes too many resources that impact others.
Examples of Governor Limits:
- 100 SOQL queries per transaction
- 150 DML statements per transaction
- 6 MB synchronous Apex heap size
- 10 callouts in a transaction
- 50,000 records retrieved per SOQL query
Where limits apply?
- Apex code
- Triggers
- SOQL, SOSL
- Callouts
- Batch and Queueable execution
- Test classes
Governor limits help developers write efficient, scalable code.
19. Why does Salesforce have Governor Limits?
Salesforce uses a multi-tenant architecture, meaning multiple customers share the same infrastructure. To ensure that no single customer monopolizes the platform’s resources, Salesforce enforces Governor Limits.
Reasons for Governor Limits:
- Fair resource allocation
Every customer gets equal access to processing power. - System stability
Prevents a poorly written trigger or Apex code from crashing the entire org. - Performance optimization
Ensures queries and operations stay efficient. - Security and data integrity
Protects against DDoS-like behavior through excessive operations. - Scalability
Ensures Salesforce can support millions of transactions per second.
Governor limits are essential to maintain consistency and performance across Salesforce’s cloud platform.
20. What is a Sandbox?
A Sandbox is a copy of your Salesforce production environment used for development, testing, training, and experimentation—without affecting live data or users.
Types of Sandboxes:
- Developer Sandbox
- Used for coding and basic testing
- Small amount of data
- Developer Pro Sandbox
- More storage than Developer Sandbox
- Partial Copy Sandbox
- Includes sample production data
- Good for UAT and integration testing
- Full Sandbox
- Exact replica of production
- Includes all data and configurations
- Best for performance testing and staging
Benefits of Sandboxes:
- Safe space to test features
- Prevents production outages
- Allows parallel development
- Ideal for training new users
- Supports CI/CD and agile development
Sandboxes make Salesforce development safe, scalable, and compliant with enterprise requirements.
21. Types of Sandboxes in Salesforce?
Salesforce provides several types of Sandboxes, each designed for specific development and testing needs. A Sandbox is essentially a copy of your production environment, allowing teams to work safely without impacting live data.
1. Developer Sandbox
- Designed for individual developers
- Contains only configuration (metadata), no production data
- Very small storage capacity
- Refresh interval: 1 day
- Best for: Coding, trigger development, and unit testing
2. Developer Pro Sandbox
- Larger storage than Developer Sandbox
- Contains configuration only
- Allows storing larger sets of test data
- Refresh interval: 1 day
- Best for: Advanced development and integration testing
3. Partial Copy Sandbox
- Contains configuration + sample production data
- Includes a limited dataset defined by a Sandbox Template
- Storage limit: Up to 5GB
- Refresh interval: 5 days
- Best for: User Acceptance Testing (UAT), QA testing, training
4. Full Sandbox
- Complete replica of production
- Includes all configuration and all production data
- Support for a sandbox template to reduce data if needed
- Refresh interval: 29 days
- Best for: Load testing, performance testing, staging, pre-production validation
Summary table:
Sandbox TypeIncludes Data?StorageBest ForRefresh TimeDeveloperNoSmallDevelopment1 dayDeveloper ProNoMediumDev & Integrations1 dayPartial CopySample5GBUAT & QA5 daysFullEntire dataEqual to productionStaging & Performance Testing29 days
22. What is a Profile?
A Profile in Salesforce is a fundamental security component that defines what a user can do within the system. It controls access at the object, field, and system levels. Every user must have exactly one Profile.
A Profile controls:
- Object permissions (Create, Read, Edit, Delete)
- Field-level security
- Page layout assignments
- App visibility
- Login hours and login IP ranges
- Permission to use tabs, records, and administrative features
- Access to Apex classes, Visualforce pages
Common Profile Types:
- Standard User
- System Administrator
- Read-Only User
- Marketing User
- Custom profiles
Profiles define a user's baseline access. To increase access without changing their profile, we use Permission Sets.
23. What is a Permission Set?
A Permission Set is a flexible, additional layer of security used to extend user permissions without modifying their Profile. Unlike Profiles (where each user can have only one), users can have multiple Permission Sets.
Purpose of Permission Sets:
- Grant users extra access temporarily or permanently
- Avoid creating too many Profiles
- Provide app-specific or feature-specific access
Permission Sets can provide:
- Object permissions
- Field-level security
- System permissions
- App access
- Apex class and Visualforce access
- Permission to use custom settings and custom metadata
Example:
If a Sales User needs access to the “Campaign” object temporarily, give them a Campaign Permission Set rather than creating a new profile.
Permission Sets make Salesforce access management more scalable and maintainable.
24. What is a Role in Salesforce?
A Role determines a user’s position in the data visibility hierarchy. While Profiles manage “what a user can do,” Roles manage what a user can see.
Roles impact:
- Record visibility
- Sharing model
- Reporting hierarchy
Users higher in the role hierarchy can see and access records owned by users below them (if sharing rules allow).
Key features of Roles:
- Support data visibility and record access
- Define reporting lines
- Optional (some orgs don’t use Roles heavily)
- Can impact organization-wide defaults and sharing behavior
Example hierarchy:
- CEO
- VP Sales
- Regional Manager
- Sales Rep
Roles are essential when teams need hierarchical visibility into sales or service records.
25. What is the difference between Role and Profile?
Roles and Profiles both control security in Salesforce but serve entirely different purposes.
Profile (What you can do)
- Controls system and functional permissions
- Object-level CRUD
- Field-level security
- Tab visibility
- App access
- Login restrictions
Every user MUST have one Profile.
Role (What you can see)
- Controls data visibility
- Impacts record sharing
- Determines reporting hierarchy
- Allows users higher in the hierarchy to see subordinate records
Roles are OPTIONAL.
Key Differences Table:
FeatureProfileRolePurposeFunctional accessData visibilityRequired?YesNoControlsCRUD, FLS, system permissionsRecord accessAffects Sharing?NoYesUsers can haveOneOneVisibilityDoes not affect dataAffects data hierarchy
In simple terms:
✔ Profile = Permissions
✔ Role = Visibility
26. What are Sharing Rules?
Sharing Rules allow automatic, criteria-based or owner-based record sharing to expand access beyond Org-Wide Defaults (OWD).
They provide a way to open up access when OWD is too restrictive.
Types of Sharing Rules:
- Owner-Based Sharing Rules
- Share records owned by users in one group with another group
- Example: Share all records owned by “East Sales Team” with “West Sales Team”
- Criteria-Based Sharing Rules
- Share records that meet specific conditions
- Example: Share all Opportunities where Amount > 1,00,000 with the “Executive Team”
Sharing Rules can share records with:
- Public Groups
- Roles
- Roles and Subordinates
- Territories
Sharing Rules help implement flexible, scalable data access models beyond simple role hierarchy.
27. What is OWD (Organization-Wide Defaults)?
OWD (Organization-Wide Defaults) defines the baseline level of access users have to each object’s records in Salesforce. It is the first and most restrictive layer of the Salesforce Sharing Model.
OWD determines whether records are:
- Public (everyone can access)
- Private (only owner can see)
- Public Read Only
- Controlled by Parent
- Public Read/Write/Transfer (Cases & Leads only)
OWD Settings Determine:
- Whether users can view, edit, or not see records they don’t own
- Sharing rule necessity
- Role hierarchy visibility
Common OWD Values:
- Private – Most restrictive; users can only see their own records
- Public Read Only – Users can view but not modify others’ records
- Public Read/Write – Users can view and modify all records
- Controlled by Parent – Record access depends on parent object
OWD is the foundation of Salesforce data security, and additional sharing models expand access from that baseline.
28. What are Page Layouts?
Page Layouts control the user interface of record detail pages in Salesforce.
They define:
- Which fields are visible
- Which fields are required
- Section organization
- Button visibility (Edit, Delete, Clone)
- Related Lists displayed on the record
Page Layouts ensure users see appropriate information depending on their role and function.
Key Features:
- Different layouts can be assigned by Profile
- Supports field-level customizations
- Helps optimize user experience
- Can hide/show related lists
- Works with Record Types for differentiated experiences
Example:
A Sales Rep and a Sales Manager may see different fields on an Opportunity record using different Page Layouts.
29. What are Record Types?
Record Types allow organizations to create different business processes, picklist values, and page layouts for the same object.
Record Types are a powerful tool for customization.
Record Types are used for:
- Different sales processes
- Different case processes
- Different picklist options for different teams
- Displaying different page layouts
Examples:
- Opportunity Record Types:
- New Business
- Renewal
- Partner Sale
- Case Record Types:
- Technical Issue
- Billing Issue
Each Record Type provides:
- Unique page layout
- Specific picklist values
- Unique process flows
Record Types allow a single object to support multiple distinct workflows.
30. What is Lightning Experience?
Lightning Experience (LEX) is the modern Salesforce user interface introduced to replace Salesforce Classic. It provides a more powerful, customizable, and productivity-focused experience.
Key Features of Lightning Experience:
- Lightning Web Components (LWC)
- Dynamic and responsive UI
- Drag-and-drop Lightning App Builder
- Enhanced dashboards and reports
- Kanban views for Opportunities, Leads, and Cases
- Path UI for guided processes
- Improved navigation
- Better integration with mobile devices
- Stronger performance and modern APIs
Benefits of Lightning Experience:
- Improves productivity with faster workflows
- Supports modern automation tools like Flow
- Enables modern UI development through LWC
- Provides dynamic forms and pages
- Enhances the overall usability of Salesforce
Lightning Experience is the future of Salesforce, and almost all new features are built exclusively for LEX.
31. What is LWC (Lightning Web Components)?
Lightning Web Components (LWC) is Salesforce’s modern, standards-based framework for building fast, efficient, and reusable user interface components. It is built using native web standards like HTML, CSS, and modern JavaScript, which makes it lightweight and performant compared to older frameworks like Aura.
Key features of LWC:
- Uses native browser capabilities (Shadow DOM, Custom Elements, Templates)
- Improved performance and faster loading
- More secure due to strict encapsulation
- Supports reusable and modular components
- Works seamlessly with Lightning Data Service (LDS)
- Can communicate with Apex to fetch or update data
Advantages of LWC:
- Better performance than Aura
- Easier development for JavaScript developers
- Cleaner code structure
- Future-proof, as Salesforce is fully moving toward LWC
- Fully supports modern JS features (ES6+, decorators, modules)
Use cases of LWC:
- Custom UI pages
- Dashboards
- Wizards
- Integration-heavy UI
- Customized record pages
LWC is now the preferred UI framework for Salesforce development and is the foundation of future UI enhancements.
32. What is Aura Component?
Aura Components (Lightning Components) are Salesforce’s earlier component-based UI framework, created before LWC. Aura uses its own programming model and is not fully based on modern web standards, which is why Salesforce gradually shifted toward LWC.
Key features of Aura Components:
- Component-driven architecture
- Supports event-driven communication
- Uses Apex for backend logic
- Can embed LWC inside Aura components
- Used widely in legacy Lightning projects
Limitations of Aura:
- Slower performance compared to LWC
- Heavier framework and more complex syntax
- Does not use native browser standards
- More boilerplate code
Although LWC is the recommended choice today, Aura Components are still maintained for backward compatibility.
33. What is Lightning App Builder?
Lightning App Builder is a drag-and-drop tool used to build custom pages for the Lightning Experience and Salesforce Mobile App. It allows admins and developers to create personalized, dynamic user interfaces without writing code.
What you can build with Lightning App Builder:
- Home Pages
- App Pages
- Record Pages
- Embedded dashboards
- Custom layouts for different profiles
Features:
- Drag-and-drop interface
- Supports standard, custom, and third-party components
- Ability to show different components based on user/record conditions
- Supports LWC and Aura components
- Dynamic forms and dynamic actions
Lightning App Builder empowers admins to create tailored and intuitive UIs without involving developers for every small change.
34. What is a Static Resource?
A Static Resource in Salesforce is a file or collection of files stored in Salesforce that can be used in Visualforce, LWC, and Aura components. It provides a way to upload and reference external assets within Salesforce.
Static Resources can include:
- CSS files
- JavaScript files
- Images
- ZIP archives
- JSON files
- Fonts or other binary data
Usage examples:
- Including CSS files in Visualforce pages
- Storing JavaScript libraries for LWC
- Hosting image assets for custom UI
- Storing JSON templates for integration logic
Benefits of Static Resources:
- Cached for better performance
- Secure and centralized
- Version-controlled (using naming conventions)
- Accessible from Apex, VF, Aura, and LWC
Static Resources make it easy to package third-party libraries and custom UI assets within Salesforce.
35. What is Apex Class?
An Apex Class is a blueprint that contains variables, methods, and logic written in the Apex programming language. Apex classes are used to implement custom business logic in Salesforce.
What Apex Classes can do:
- Execute business logic
- Call external APIs
- Query and manipulate Salesforce data
- Implement reusable logic across multiple triggers and components
- Serve as controllers for Visualforce and LWC
- Run asynchronously (Batch, Queueable, Scheduled Apex)
Example Apex Class:
public class AccountHandler {
public static void updateAccounts(List<Account> accList) {
update accList;
}
}
Apex classes are essential for building sophisticated Salesforce applications and custom solutions.
36. What is Test Class in Salesforce?
A Test Class in Salesforce is a special type of Apex class used to validate and test Apex code. Salesforce requires that every piece of Apex code be covered by test methods before deployment.
Purpose of Test Classes:
- Ensure code behaves correctly
- Prevent regressions
- Simulate system behavior
- Verify bulk operations
- Validate error handling
- Ensure governor limits are respected
Features of Test Classes:
- They do not access actual org data
- Must insert their own test data
- Use @isTest annotation
- Must cover at least 75% of Apex code for deployment
Example Test Class:
@isTest
public class AccountHandlerTest {
@isTest
static void testUpdateAccounts() {
Account acc = new Account(Name='Test');
insert acc;
acc.Name = 'Updated Name';
AccountHandler.updateAccounts(new List<Account>{acc});
Account updated = [SELECT Name FROM Account WHERE Id = :acc.Id];
System.assertEquals('Updated Name', updated.Name);
}
}
Test Classes improve the reliability and maintainability of Apex code.
37. What is Data Loader?
Data Loader is a client application provided by Salesforce to import, export, update, upsert, or delete large volumes of data. It is used by developers, admins, and data teams for heavy data operations that cannot be handled by simple tools.
Key capabilities of Data Loader:
- Insert records
- Update existing records
- Upsert (insert or update)
- Delete records
- Export data
- Mass extract data using SOQL
Benefits:
- Supports up to 5 million records (or more via Bulk API)
- Powerful error handling
- Supports CSV files
- Can automate tasks using command-line scripts
- Ideal for data migration or cleanup
Data Loader is the most commonly used tool for bulk data manipulation in Salesforce.
38. What is the difference between Data Import Wizard and Data Loader?
Both tools help import data, but they serve different purposes.
Data Import Wizard
- Web-based tool inside Salesforce
- Easy to use, no installation required
- Supports up to 50,000 records
- Limited operations (insert/update only)
- Best for non-technical users
Data Loader
- Desktop application
- Supports millions of records
- Supports insert, update, upsert, delete, export
- Can use Bulk API
- Allows automation through command-line
Comparison Table:
FeatureData Import WizardData LoaderRecord limit50,0005 million+OperationsInsert, UpdateInsert, Update, Upsert, Delete, ExportTechnical levelBeginnerIntermediate/AdvancedInstallationNoYesAutomationNoYes (CLI)
Use Data Import Wizard for small tasks.
Use Data Loader for large-scale data operations.
39. What is the Recycle Bin in Salesforce?
The Recycle Bin is a Salesforce feature that stores deleted records temporarily, allowing users or admins to restore them if deleted accidentally.
Key features:
- Stores deleted records for 15 days (default)
- Admins can access all deleted records
- Users can restore their own deleted records
- Supports permanent delete (Empty Recycle Bin)
- Restores record relationships if possible
What can be restored?
- Standard object records (Accounts, Contacts, Leads, Cases)
- Custom object records
- Most child records if parents still exist
The Recycle Bin is essential for preventing data loss and managing accidental deletions.
40. What is the significance of 75% code coverage in Salesforce?
Salesforce requires that 75% of Apex code be covered by test methods before deploying to production. This ensures quality, reliability, and compliance across the Salesforce ecosystem.
Reasons for the 75% requirement:
- Code reliability
Ensures that most logic is tested for success and failure scenarios. - Platform trust and stability
Prevents buggy code from being deployed in a multi-tenant environment. - Ensures best development practices
Encourages developers to follow good testing methodologies. - Protects existing functionality
Helps catch regressions when making updates. - Mandatory for production deployment
Without meeting 75%, Salesforce will not allow deployment.
Important notes:
- Every trigger must have at least 1% coverage
- All classes contribute to an org-wide coverage score
- Test Classes do not count toward code limits
- More coverage does NOT guarantee better code—quality matters
Test coverage ensures that Salesforce environments remain stable and reliable even during continuous enhancements.
Intermediate (Q&A)
1. Explain the order of execution in Salesforce.
The Order of Execution in Salesforce is the sequence in which Salesforce processes operations when a record is inserted, updated, deleted, or undeleted. Understanding this sequence is critical for designing triggers, automation, validation rules, and integrations without causing conflicts or unexpected behavior.
Full Salesforce Order of Execution (Detailed):
- System Validation Rules
- Checks field data types, required fields, and field formats
- Ensures layout-level requirements are satisfied
- Before Triggers
- Executes all before insert, before update, or before delete triggers
- System Validation (again)
- Custom validation rules
- Duplicate rules
- Before-save flows
- Record Is Saved to Database (but not committed)
- ID is generated for new records
- No commit yet
- After Triggers
- Executes after insert/update/delete/undelete triggers
- Record ID becomes available for use
- Assignment Rules
- For Leads or Cases
- Assigns to queues/users
- Auto-response Rules
- Sends auto messages for Leads/Cases
- Workflow Rules
- Field updates
- Tasks
- Email alerts
- Outbound messages
- Workflow Field Updates (WFR FU) Re-evaluation
- Triggers and validation rules may run again
- Can cause recursion if not handled properly
- Processes (Process Builder)
- Flows (After-save Flows)
- Escalation Rules
- Entitlements & Roll-up summaries
- Grand-parent roll-up recalculations
- Commit (DML committed to database)
- Post-commit logic
- Emails
- Async Apex (Queueable, Future, Batch)
- Platform Events
- Outbound events
Mastering the order of execution ensures stable, predictable automations and prevents infinite loops.
2. What is a Trigger Context Variable?
Trigger Context Variables are system-provided variables in Apex triggers that give developers important information about the current trigger execution such as:
- whether it’s a before/after trigger
- whether it's insert/update/delete
- what records are being processed
- what was the old/new state of records
They are available inside the Trigger class.
Common Trigger Context Variables:
VariableMeaningTrigger.isInsertTrue if trigger fired by insertTrigger.isUpdateTrue if fired by updateTrigger.isDeleteTrue if fired by deleteTrigger.isBeforeTrue before saving to DBTrigger.isAfterTrue after saving to DBTrigger.newNew version of recordsTrigger.oldOld version of records (update/delete)Trigger.newMapMap of new records keyed by IdTrigger.oldMapMap of old records keyed by Id
Example Use Case:
if(Trigger.isUpdate && Trigger.isAfter){
// Run logic after updating records
}
Context variables are essential for writing clean, correct, and bulkified Apex triggers.
3. What is Bulkification and why is it important?
Bulkification is the process of writing Apex code that can handle multiple records at once, instead of processing one record at a time.
Salesforce enforces strict governor limits, so bulkification ensures that your code does not exceed those limits during mass operations like:
- Data Loader imports
- Batch Apex
- Integration calls
- Mass updates in UI
Why Bulkification is Critical:
- Prevents hitting governor limits (SOQL, DML, CPU time)
- Ensures performance and scalability
- Essential for multi-record operations
- Triggers always run in bulk (even if one record is saved through UI)
Non-bulkified code example (BAD):
for(Account acc : Trigger.new) {
insert new Contact(LastName='Test', AccountId=acc.Id);
}
This causes 1 DML per record → governor limit violation.
Bulkified version (GOOD):
List<Contact> contacts = new List<Contact>();
for(Account acc : Trigger.new) {
contacts.add(new Contact(LastName='Test', AccountId=acc.Id));
}
insert contacts;
Bulkification is the most important best practice for Apex development.
4. How do you prevent recursive triggers?
Recursive triggers occur when a trigger updates the same object, causing the trigger to fire again and again, potentially causing infinite loops.
Common Techniques to Prevent Recursion:
- Static Boolean Flags
public class TriggerControl {
public static Boolean isExecuting = false;
}
Trigger:
if(!TriggerControl.isExecuting){
TriggerControl.isExecuting = true;
// logic
}
Set storing record IDs processed
if(!TriggerControl.processedIds.contains(rec.Id)){
TriggerControl.processedIds.add(rec.Id);
}
Compare old and new valuesExecute code only when meaningful changes occur:
if(Trigger.new[i].Status != Trigger.old[i].Status) {
// run logic
}
- Use “before” triggers instead of “after” when possible
- Use Trigger Handler Frameworks
Frameworks naturally reduce recursion risk.
Preventing recursion protects the system from governor limit failures and unexpected behavior.
5. What is a Trigger Handler Framework?
A Trigger Handler Framework is a structured design pattern that separates trigger logic from business logic. Instead of placing logic directly inside triggers, all logic is moved into handler classes.
Benefits:
- Cleaner, modular code
- Easy maintenance and debugging
- Prevents recursion
- Enforces bulkification
- Supports multiple trigger events without multiple triggers
- Enhances testability
Common Framework Structure:
- One trigger per object
- Trigger routes events to handler class
- Handler class contains methods for each event
- Optional recursion guards
Trigger:
trigger AccountTrigger on Account (before insert, before update, after insert) {
AccountTriggerHandler handler = new AccountTriggerHandler();
handler.run();
}
Frameworks are a must-have for enterprise-grade Salesforce development.
6. Explain different types of Apex Collections.
Apex provides three main collection types:
1. List
- Ordered collection of elements
- Allows duplicates
- Indexed
Example:
List<String> names = new List<String>();
2. Set
- Unordered collection
- No duplicates allowed
- Great for filtering and preventing repetition
Example:
Set<String> emails = new Set<String>();
3. Map
- Key-value pairs
- Keys must be unique
- Powerful for lookups by Id
Example:
Map<Id, Account> accMap = new Map<Id, Account>(accList);
Usage in Salesforce:
- Lists for DML (insert List<>)
- Sets for unique filters in SOQL WHERE Id IN :set
- Maps for efficient object lookups
Collections are fundamental for bulkified and optimized Apex coding.
7. What is a Wrapper Class?
A Wrapper Class is a custom Apex class that encapsulates multiple data types into a single object. It is used to combine different fields, objects, and data structures for display or processing.
Why Wrapper Classes are used:
- To display complex data structures in LWC/VF pages
- Handle selectable data (checkboxes in tables)
- Combine multiple objects into a single list
- Prepare custom API response objects
- Avoid using sObjects directly in UI
Example Wrapper Class:
public class AccountWrapper {
public Account acc { get; set; }
public Boolean isSelected { get; set; }
public AccountWrapper(Account a, Boolean s) {
acc = a;
isSelected = s;
}
}
Wrapper classes improve UI control and structured data handling.
8. What is the difference between List, Set, and Map?
FeatureListSetMapOrderOrderedUnorderedUnorderedDuplicatesAllowedNot allowedKeys uniqueAccessBy indexNo indexBy keyBest forDML, ordered dataUnique filteringFast lookups
Examples:
- List: Insert/update operations → requires List
- Set: Remove duplicate Ids → use Set
- Map: Build data lookup tables → use Map<Id, Object>
Each collection is optimized for a specific type of Salesforce operation.
9. How do you handle exceptions in Apex?
Exception handling ensures Apex code fails gracefully instead of crashing.
Use try-catch Block
try {
update accounts;
} catch(Exception e) {
System.debug('Error: ' + e.getMessage());
}
Best Practices for Exception Handling:
- Log exceptions (custom logging table)
- Use meaningful messages
- Never hide errors silently
- Use custom exceptions
public class MyCustomException extends Exception {}
Use addError() in triggers
Trigger.new[i].addError('Invalid data');
- Avoid swallowing exceptions
Useful for debugging and user notifications.
Effective exception handling ensures stability and improves maintainability.
10. What are Custom Metadata Types?
Custom Metadata Types (CMTs) are Salesforce configuration records used to store application settings and custom logic parameters. The biggest advantage: Custom Metadata is deployable and packageable, unlike Custom Settings.
Benefits of Custom Metadata:
- Deployable via change sets, metadata API, packages
- Cached for high performance
- Does NOT count against SOQL limits
- Ideal for storing config that should not vary by org
- Fully accessible in Apex, Flow, LWC
- No need to write test data—available in tests by default
Use Cases:
- Feature toggles
- API endpoint configurations
- Validation rule parameters
- Mapping tables
- Integration settings
Example Access in Apex:
List<My_Metadata__mdt> configs = [
SELECT Field__c FROM My_Metadata__mdt
];
Custom Metadata Types are essential for scalable, configurable enterprise applications.
11. Difference between Custom Metadata and Custom Settings?
Custom Metadata and Custom Settings are both used to store configuration data in Salesforce, but they behave very differently in terms of deployment, access, and performance.
Custom Metadata (CMT)
Custom Metadata Types are deployable configuration records used to store application settings that remain consistent across all environments.
Key Features:
- Deployable using change sets, metadata API, or unlocked packages
- Records are treated as metadata, not data
- Accessible in Apex without SOQL (cached)
- Included automatically in test context
- Supports version control
- Best for static, org-wide configurations
Use Cases:
- API endpoints
- Feature toggles
- Country or business rule configurations
- Mapping tables (e.g., record type to queue mapping)
Custom Settings
Custom Settings are like application variables stored inside Salesforce. They behave like lightweight storage for org or user-specific preferences.
Two Types:
- List Custom Settings (similar to custom object records)
- Hierarchy Custom Settings (values differ per user/profile/org)
Key Features:
- Faster access than normal objects
- Not deployable (data must be migrated separately)
- Best for values that may differ by user or profile
- Requires SOQL to access List Custom Settings (but not Hierarchy)
Use Cases:
- User preference settings
- Limits that vary by profile
- Thresholds for business processes
Comparison Table
FeatureCustom MetadataCustom SettingsDeployableYesNoTest Class DataAvailable automaticallyMust be createdAccess SpeedVery fast (cached)FastSOQL RequiredNoSometimesVersion ControlSupportedNot supportedBest ForStatic configurationsUser/org-level dynamic settings
Conclusion:
Use Custom Metadata for system-level configuration and Custom Settings for user/profile-specific preferences.
12. What is a Future Method?
A Future Method in Apex is a way to perform operations asynchronously, in a separate execution thread. It is used when the process does not need to be completed immediately.
Key Features of Future Methods:
- Must be annotated with @future
- Executes independently of the main transaction
- Supports callouts using
@future(callout=true) - Used for long-running operations
- Cannot return values
- Parameters must be primitive types, arrays, or collections
Common Use Cases:
- Making callouts from triggers
- Performing resource-heavy operations
- Handling large data updates in background
- Logging operations
- Integrations
Example:
@future(callout=true)
public static void updateAccounts(List<Id> accIds) {
// long-running logic
}
Future methods help maintain governor limits, improve user performance, and avoid blocking UI operations.
13. What is Queueable Apex?
Queueable Apex is an enhanced asynchronous Apex execution method that allows:
- Complex job chaining
- Passing objects (not allowed in future methods)
- Better control over async execution
- Monitoring through the Apex Jobs page
It is more flexible and powerful than future methods.
Key Features:
- Implements
Queueable interface - Allows job chaining (
System.enqueueJob()) - Supports Database.Stateful
- Supports callouts
- Allows passing complex objects
Example:
public class ProcessAccounts implements Queueable {
public void execute(QueueableContext context) {
// logic
}
}
// Enqueue
System.enqueueJob(new ProcessAccounts());
Queueable Apex is ideal for async processing that needs sequencing or complex data.
14. Difference between Batch Apex and Queueable?
Batch and Queueable Apex are both asynchronous, but they serve different purposes.
Batch Apex
- Used for processing millions of records
- Breaks data into small chunks (default 200 records per batch)
- Supports
start, execute, and finish methods - Long-running and scalable
- Has governor limit reset per batch
Best For:
Large data processing, ETL, cleanup, migrations
Queueable Apex
- More flexible than future methods
- Allows job chaining
- Supports passing objects
- Executes once, no batch slicing
- Better for smaller async jobs
Best For:
Small to medium asynchronous tasks, API calls, chained operations
Comparison Table
FeatureBatch ApexQueueable ApexData VolumeMillionsModerateChainingLimitedUnlimited chainingStateful supportYesYesSlicingAutomatic batchesNo slicingComplexityHigherMedium
Batch is for large-scale jobs, Queueable is for flexible asynchronous logic.
15. What is Scheduled Apex?
Scheduled Apex allows developers to schedule classes to run at specific times, similar to cron jobs.
Requirements:
- Class must implement
Schedulable interface - Must define
execute(SchedulableContext sc) method
Example:
public class DailyJob implements Schedulable {
public void execute(SchedulableContext sc) {
// logic here
}
}
Scheduling Example:
String cron = '0 0 2 * * ?'; // Runs every day at 2 AM
System.schedule('Daily Job', cron, new DailyJob());
Use Cases:
- Daily data cleanup
- Nightly batch jobs
- Automated email reports
- Recurring integrations
- Scheduled maintenance tasks
Scheduled Apex enables automated background tasks without manual intervention.
16. What are Lightning Events in Aura?
Lightning Events enable communication between Aura components.
There are three types:
1. Application Events
- Broadcast across the entire app
- Any component can handle them
- Used for cross-component communication
2. Component Events
- Fired from a child component
- Handled by parent component
- Works like event bubbling
3. System Events
- Provided by the framework (e.g., initialization events)
Use Cases:
- Inter-component communication
- Sending data from child to parent
- Synchronizing UI components
LWC does not use Aura events; it uses custom events and Lightning Message Service, but Aura Events remain essential for legacy projects.
17. What is LDS (Lightning Data Service)?
Lightning Data Service (LDS) is the data-handling engine for Lightning Components (Aura and LWC). It provides declarative access to Salesforce data, without Apex.
Benefits:
- No Apex required
- Handles caching automatically
- Prevents duplicate server calls
- Enforces security (CRUD & FLS)
- Manages record sharing
- Supports UI and database sync
Use Cases:
- Displaying and editing records
- Reducing SOQL queries
- Sharing record data across components
LDS behaves like a mini data cache inside Lightning, improving performance and reducing server load.
18. Explain Component Lifecycle for LWC.
LWC components go through several lifecycle phases when rendered, updated, and destroyed.
LWC Lifecycle Hooks:
- constructor()
- Initializes component
- No access to DOM
- No data yet available
- connectedCallback()
- Fires when component is inserted into the DOM
- Safe place for initializations, event listeners, data loading
- renderedCallback()
- Called after every render (initial + re-render)
- DOM elements are available
- Used for post-render logic
- disconnectedCallback()
- Fires when component is removed from DOM
- Used to clean up listeners or timers
- errorCallback(error, stack)
- Handles component errors gracefully
Lifecycle management is crucial for memory optimization, event handling, and component performance.
19. What is @wire decorator in LWC?
@wire is a powerful decorator in LWC used to connect components to Salesforce data sources such as:
- Apex methods
- Lightning Data Service
- UI API
Key Features:
- Supports reactive data fetching
- Automatically refreshes when parameters change
- No need for explicit promises
- Uses reactive variables (
$variable syntax)
Example: Wire Apex
@wire(getAccounts) accounts;
Wire with Parameters
@wire(getContacts, { accId: '$recordId' })
contacts;
Benefits:
- Auto-refresh
- Error and data tracking
- Less boilerplate code
- Better performance
@wire is ideal for read-only or frequently-updated data.
20. How do you call Apex from LWC?
LWC can call Apex in two ways:
1. Wired Apex
Used for read-only, reactive data retrieval.
@wire(getAccounts) accounts;
Benefits: Caching, auto-refresh, fewer server calls.
2. Imperative Apex
Used when you want to call Apex manually, usually triggered by user actions (button clicks, form submissions).
import getAccounts from '@salesforce/apex/AccountController.getAccounts';
handleClick() {
getAccounts()
.then(result => {
this.data = result;
})
.catch(error => {
this.error = error;
});
}
Benefits:
- Full control over execution
- Best for create/update operations or when you need dynamic parameters
Key Requirements:
- Apex methods must be
@AuraEnabled(cacheable=true) for wired calls - Must be
@AuraEnabled for imperative calls - Must be static Apex methods
Calling Apex from LWC provides flexibility to perform server-side logic seamlessly.
21. What is the difference between imperative and wired Apex calls?
LWC communicates with Apex using two main approaches: wired calls and imperative calls, each designed for different purposes.
Wired Apex Calls
Wired calls use the @wire decorator to fetch data reactively. They automatically refresh when reactive parameters change or when Salesforce updates the cached data.
Key Features:
- Reactive and automated
- Cacheable responses using
cacheable=true - Declarative and cleaner syntax
- Best for retrieving data (GET operations)
- Automatically handles errors, loading state, and updates
Example:
@wire(getAccounts) accounts;
Imperative Apex Calls
Imperative calls are explicit and manually triggered by user interactions such as button clicks.
Key Features:
- Called inside JS functions
- Good for create/update/delete operations
- Useful when you need precise control
- Supports async/await and promise handling
- Not reactive
- Does NOT use caching
Example:
getAccounts()
.then(result => { this.data = result; })
.catch(error => { this.error = error; });
Comparison Table
FeatureWiredImperativeExecutionAutomaticManualUse caseFetch dataCreate/update/deleteCacheableYesNoReactivityYesNoControl levelLowHigh
Summary:
Use wired for reactive, read-only UI data.
Use imperative when you need manual control or when performing writes.
22. What is Lightning Message Service (LMS)?
Lightning Message Service (LMS) is a cross-technology communication mechanism that allows LWC, Aura, and Visualforce pages to communicate with each other, even if they exist in separate DOMs or iframes.
Why LMS exists:
Traditional component communication was limited to:
- Parent-child communication
- Aura events
- Application events (Aura only)
LMS solves this by providing a unified messaging channel.
Key Features of LMS:
- Works across LWC ↔ Aura ↔ Visualforce
- No need for event bubbles or component hierarchy
- Channel-based publish/subscribe model
- Secure and lightweight
- Works in Lightning Experience and Mobile App
Use Cases:
- Synchronizing UI between components
- Broadcasting notifications or status updates
- Communicating between VF and LWC
- Updating components hosted in different containers
LMS is the most powerful and modern communication mechanism for multi-framework Salesforce apps.
23. What is AuraEnabled annotation?
The @AuraEnabled annotation is used in Apex to expose methods, variables, or properties to Aura components and LWC.
Two common uses:
1. Expose Apex Methods
@AuraEnabled
public static List<Account> getAccounts() { ... }
For LWC wired calls:
@AuraEnabled(cacheable=true)
2. Expose Data Structure
@AuraEnabled public String name { get; set; }
Key Features:
- Required for LWC and Aura to call Apex
- Ensures method is accessible in UI context
- Supports cacheable calls with
cacheable=true - Supports complex return types like lists, maps, wrappers
This annotation bridges backend Apex and frontend Lightning components.
24. What is API Versioning in Salesforce?
API Versioning refers to the version number assigned to Apex classes, LWC components, Visualforce pages, and Salesforce APIs. Each version includes certain features, bug fixes, and behavior changes.
Why API versioning matters:
- Prevents older code from breaking
- Allows gradual migration to modern features
- Ensures backward compatibility
- Developers can choose which version of platform behavior they need
Where API version is used:
- Apex classes
- LWC (metadata file)
- Aura components
- Visualforce pages
- Salesforce REST/SOAP APIs
Example: Apex API version
<apiVersion>58.0</apiVersion>
Using the right API version ensures consistent behavior across deployments and upgrades.
25. What is a Connected App?
A Connected App is a framework that allows external applications to integrate with Salesforce using OAuth, SAML, or OpenID Connect.
What Connected Apps provide:
- Token-based authentication
- Access to Salesforce APIs
- Single Sign-On (SSO)
- Control over scopes (like read, write, refresh tokens)
- Access policies (IP range, session timeout)
- User revocation and monitoring
Use Cases:
- Integrating mobile apps
- Integrating third-party apps like Google, AWS, Slack
- Custom web apps needing Salesforce authentication
- API-based integrations (REST/SOAP/Bulk APIs)
Connected Apps are the gateway for secure authentication and external integration.
26. What is the use of Named Credentials?
Named Credentials simplify external callouts by securely storing:
- Endpoints
- Authentication details (OAuth, basic auth)
- Tokens
- Certificates
They eliminate the need to hardcode authentication logic inside Apex.
Why Named Credentials are valuable:
- Security: No credentials in code or custom settings
- Simplicity: One line of Apex can authenticate automatically
- Flexibility: Easily update endpoints without redeployment
- Supports OAuth flows
Example Callout Using Named Credential:
HttpRequest req = new HttpRequest();
req.setEndpoint('callout:WeatherAPI/weather/today');
All authentication is handled automatically. Named Credentials are the best practice for secure integrations.
27. How do you integrate Salesforce with REST API?
Salesforce can consume or expose REST APIs.
1. Salesforce as Caller (Consuming REST API)
Steps:
- Create Named Credential for authentication
- Write Apex callout using
HTTP and HTTPRequest - Process JSON response using
JSON.deserialize - Handle errors and retry logic
Example:
Http http = new Http();
HttpRequest req = new HttpRequest();
req.setEndpoint('callout:MyAPI/getData');
req.setMethod('GET');
HttpResponse res = http.send(req);
2. Salesforce as Provider (Exposing REST API)
Steps:
- Create Apex class annotated with
@RestResource - Expose methods using
@HttpGet, @HttpPost, etc. - Salesforce generates an endpoint automatically
Example:
@RestResource(urlMapping='/accounts/*')
global with sharing class AccountRESTService {
@HttpGet
global static Account getAccount() { ... }
}
REST integration is the most common enterprise integration method.
28. How do you integrate Salesforce with SOAP API?
Similar to REST, Salesforce can both consume and expose SOAP services.
1. Salesforce Consuming SOAP Services
Steps:
- Import the WSDL file into Salesforce
- Salesforce auto-generates Apex classes
- Instantiate the class
- Invoke remote SOAP methods
Example:
MyServicePort service = new MyServicePort();
String result = service.getData();
2. Salesforce Exposing SOAP Services
Steps:
- Create Apex class with
global scope - Use
webservice keyword - Salesforce auto generates WSDL
Example:
global with sharing class MySOAPService {
webservice static String getStatus() {
return 'OK';
}
}
SOAP is commonly used in legacy enterprise systems (banks, ERPs, etc.)
29. What is Platform Events?
Platform Events are Salesforce’s enterprise event-driven architecture mechanism used to publish and subscribe to real-time messages inside and outside Salesforce.
Features:
- Asynchronous communication
- Decoupled systems
- High-volume event handling
- Ordered and reliable delivery
Use Cases:
- Integration with external systems
- Logging and monitoring
- Triggering asynchronous flows
- IoT device communication
- Microservice communication
Events can be consumed by:
- Apex triggers
- Flows
- Process Builder
- CometD via Streaming API
- External systems (AWS, Heroku, etc.)
Platform Events enable real-time, scalable distributed communication.
30. What is Change Data Capture (CDC)?
Change Data Capture (CDC) is a mechanism that publishes events whenever Salesforce records are created, updated, deleted, or undeleted. External systems can subscribe to these events to stay synchronized with Salesforce.
Key Features:
- Real-time capture of data changes
- Supports all CRUD operations
- Guaranteed delivery
- Replay capability
- High-performance streaming
- Automatic schema generation
Use Cases:
- Sync Salesforce with external databases
- Update downstream ERP systems
- Event-driven microservices
- Audit and logging
- Near real-time data pipelines
CDC allows systems to remain synchronized without constant API polling, making integrations more efficient and scalable.
31. What is Shield Encryption?
Salesforce Shield Encryption (part of Salesforce Shield) is an advanced security offering that provides enhanced data protection for sensitive information stored in Salesforce. Unlike standard platform encryption, Shield allows organizations to encrypt a wider range of fields and data types while maintaining application functionality.
Key Features of Shield Encryption:
- Data at Rest Encryption
Encrypts data stored in:- Standard and custom fields
- Files
- Attachments
- Search indexes
- Bring Your Own Key (BYOK)
Organizations can upload and manage their own encryption keys, giving full control over key lifecycle and rotation. - Deterministic & Probabilistic Encryption
- Deterministic: Supports filtering, sorting, and indexing
- Probabilistic: Highest security level but no filtering
- Event Monitoring Integration
Works with Shield Event Monitoring for enhanced visibility and auditing. - Platform Integrity
Ensures data integrity and strict compliance with regulations like HIPAA, GDPR, FINRA, FISMA.
Why Shield Encryption Is Needed:
- Protects sensitive data like SSNs, credit card numbers, medical data
- Supports compliance frameworks
- Reduces risk of data breaches
- Allows secure integration with external systems
Shield Encryption enables organizations to use Salesforce for highly regulated data without compromising security or usability.
32. How do you handle large data volumes (LDV) in Salesforce?
Handling LDV (Large Data Volumes) means designing systems that efficiently manage millions of records in Salesforce. Poor design can lead to timeouts, long queries, and performance issues.
Strategies for Handling LDV:
1. Use Selective SOQL Queries
- Index important fields
- Avoid
LIKE '%value%' filters - Avoid negative filters (
!=, NOT IN) - Ensure filters use indexed fields for high performance
2. Use Skinny Tables
Salesforce internally creates skinny tables for frequently queried fields, speeding up queries.
3. Use Query Optimization Techniques
- Avoid joins on large objects
- Avoid complex subqueries
- Use LIMIT filters to restrict row count
4. Use Salesforce Big Objects
Designed for billions of records with async processing.
5. Use Asynchronous Processing
Use:
- Batch Apex
- Queueable Apex
- Scheduled Apex
- Platform Events
Async Apex handles large loads better.
6. Reduce Data Storage
- Archive old records
- Delete unnecessary records
- Use external systems for reporting
7. Use External Objects / Salesforce Connect
Store large datasets outside Salesforce and access them virtually.
8. Avoid Trigger Loops and Excess Logic
Use trigger frameworks and avoid expensive per-record operations.
LDV best practices ensure Salesforce remains fast, scalable, and reliable even with millions of records.
33. What is Skinny Table?
A Skinny Table is a Salesforce-managed, read-only database table that contains a subset of fields from a standard or custom object. Salesforce creates Skinny Tables to optimize queries on objects with large data volumes.
Characteristics of Skinny Tables:
- Contains a few selected fields
Copy of fields that are frequently queried - Automatically synced
Salesforce handles data synchronization internally. - Improves query performance
Skinny tables avoid joins and complex table lookups. - Cannot be updated directly
Only Salesforce can generate and manage Skinny Tables. - Used behind the scenes
Developers cannot modify or explicitly create them.
When to request a Skinny Table:
- When object has > millions of records
- When queries are slow despite selective filters
- When multiple joins and lookups slow SOQL performance
Skinny tables are a hidden performance booster for LDV scenarios.
34. What are Salesforce Governor Limits for SOQL, DML, heap, etc.?
Salesforce enforces governor limits to ensure fair resource sharing in a multitenant environment.
Key Apex Governor Limits (synchronous):
SOQL Limits
- 100 SOQL queries per transaction
- 50,000 records returned per SOQL query
DML Limits
- 150 DML statements per transaction
- 10,000 records processed per DML operation
CPU Time
- 10,000 ms (10 seconds) synchronous
- 60,000 ms (60 seconds) async
Heap Size
- 6 MB synchronous
- 12 MB asynchronous
Callouts
- 100 HTTP callouts per transaction
- Maximum timeout: 120 seconds
Future Calls / Queueable
- 50 future calls
- 50 Queueable jobs chained
Batch Apex
- 5 concurrent batch jobs
- 10,000 batch jobs scheduled
Email Limits
- 5,000 single emails per day
- Mass email limits vary by org
Understanding these limits is essential to write scalable, bulkified, and efficient Apex code.
35. What is the difference between synchronous and asynchronous Apex?
Salesforce offers two execution models:
Synchronous Apex
- Executes immediately
- User waits for completion
- Limited by smaller governor limits
- Ideal for real-time logic on UI
Examples:
- Triggers
- Apex classes called from UI
- Controller actions
Asynchronous Apex
- Runs in a separate thread
- Large limits
- Does not block UI
- Ideal for long-running or large-volume tasks
Types of Asynchronous Apex:
- Future methods
- Queueable Apex
- Batch Apex
- Scheduled Apex
- Platform Events
Comparison Table:
FeatureSynchronousAsynchronousExecutionImmediateBackgroundLimitsLowHigherBest forUI interactionsLarge data, calloutsResponseReal-timeDeferred
Asynchronous Apex is critical for LDV operations and integrations.
36. What is Deployment using Change Sets?
Change Sets are Salesforce’s point-and-click deployment tool used to migrate metadata between connected orgs (e.g., Sandbox → Production).
Key Features:
- No code required
- Easy UI-based packaging
- Can send:
- Apex classes
- Triggers
- Flows
- Objects
- Fields
- Layouts
- Profiles & Permission sets
Limitations:
- Only works between connected orgs
- Cannot deploy all metadata types
- Manual addition of components
- Change Sets cannot be version-controlled
Change Sets are ideal for smaller teams or simple deployments.
37. What is deployment using Metadata API / CI/CD?
Metadata API enables advanced deployments using automation tools like:
- Salesforce CLI (SFDX)
- GitHub Actions
- Azure DevOps
- Jenkins
- Bitbucket Pipelines
This approach supports CI/CD pipelines, version control, and automation.
Benefits of CI/CD Deployment:
- Automated deployments
- Pull-request based workflow
- Version control through Git
- Ability to deploy to multiple orgs
- Supports all metadata types
- Reliable and repeatable
Metadata API Tools:
- SFDX CLI
- ANT Migration Tool
- Jenkins or GitHub CI pipelines
Metadata API is essential for modern DevOps-driven Salesforce development.
38. How do you use ANT Migration Tool?
The ANT Migration Tool is a command-line tool based on Apache ANT for deploying and retrieving metadata via Salesforce Metadata API.
Steps to Use ANT Tool:
1. Install Java & ANT Tool
Ensure Java SDK is installed.
2. Configure build.properties
sf.username=yourusername
sf.password=yourpassword+securitytoken
sf.serverurl=https://login.salesforce.com
3. Create package.xml
Defines which metadata to retrieve or deploy.
4. Run Retrieve Command
ant retrieve
5. Run Deploy Command
ant deploy
Use Cases:
- Deploy between orgs
- Backup metadata
- Full automation in CI/CD pipelines
ANT is powerful for complex deployments, especially when Change Sets fall short.
39. What is the difference between a Permission Set and Permission Set Group?
Permission Set
A Permission Set is a bundle of additional permissions assigned to users to give extra access on top of their profile.
Used for:
- Granting object permission
- Flow access
- System permissions
- Apex class access
Users can have multiple Permission Sets.
Permission Set Group
A Permission Set Group combines multiple Permission Sets into a single assignable unit.
Benefits:
- Easier to manage large permission models
- Can add/remove Permission Sets dynamically
- Supports Muting Permission Sets (remove unwanted permissions)
Use Cases:
- Assigning role-based access
- Grouping permissions for teams (e.g., Sales Manager group)
- Reducing admin overhead
Permission Set Groups simplify permission management in large orgs.
40. What security considerations should a developer follow in Salesforce?
Security is critical in Salesforce development. Developers must adhere to platform security best practices.
1. Enforce CRUD & FLS
Always check user permissions before performing record or field access.
Example:
if(Schema.sObjectType.Account.fields.Name.isAccessible())
2. Avoid SOQL Injection
Use binding variables:
WHERE Name = :inputValue
3. Use With Sharing
Ensure classes enforce org-wide sharing rules:
public with sharing class MyClass { }
4. Secure External Integrations
- Use Named Credentials
- Avoid storing passwords in Apex
- Use OAuth for secure authentication
5. Avoid Storing Sensitive Data
- Use Platform Encryption / Shield
- Avoid unnecessary logs
6. Use Proper Validation for Inputs
Validate Apex inputs and Lightning inputs to prevent data corruption.
7. Handle Exceptions Securely
- Log errors
- Avoid exposing internal details to users
8. Apply Principle of Least Privilege
Give only the minimum permissions required.
9. Avoid Hardcoding IDs
Instead, use:
- Custom metadata
- Schema methods
10. Use Security Scans
Use Salesforce PMD, Checkmarx, and security scanners to validate code.
