Salesforce Interview Questions

Governor limits are runtime limits enforced by Salesforce to ensure efficient processing and fair use of resources in the multi-tenant environment. Because many organisations share the same underlying infrastructure, these limits prevent any single tenant from monopolising server resources. Key limits include 100 SOQL queries, 150 DML statements, and 6 MB heap size per synchronous transaction.

Trigger.new is a list of the new versions of sObject records being processed. Trigger.newMap is a map of IDs to the new versions of sObject records. Trigger.newMap is useful when you need to quickly look up a record by ID without iterating through a list. Trigger.new is only available in insert and update triggers; Trigger.newMap is available in before update, after insert, after update, and after undelete triggers.

Bulkification means writing Apex code that can handle a collection of records (up to 200 in a trigger batch) efficiently rather than processing one record at a time. Best practices include: (1) collecting all record IDs/values in Sets/Maps before the loop, (2) performing a single SOQL query outside the loop, (3) collecting DML operations in Lists/Maps and performing a single DML statement after the loop. This prevents hitting governor limits when large data volumes are processed.

Both execute code asynchronously, but Queueable Apex is more powerful: (1) It allows non-primitive parameters (sObjects, custom types), whereas @future only accepts primitive types. (2) Queueable jobs return a job ID so you can monitor them. (3) Queueable classes can chain jobs by enqueuing another job within the execute() method. (4) @future methods cannot be called from Batch Apex or other @future methods in the same transaction, while Queueable has fewer restrictions.

SOSL (Salesforce Object Search Language) performs text searches across multiple objects and fields simultaneously. Use SOSL when: (1) You don't know which object or field contains the value. (2) You need to search across multiple objects in one query. (3) You're implementing a general search feature. Use SOQL when you know the exact object and fields you're querying and need precise filtering, aggregation, or relationship queries.

The Apex order of execution when saving a record: (1) System validation (required fields, field formats). (2) Before Triggers. (3) Custom validation rules. (4) Duplicate rules. (5) Record saved to database (but not committed). (6) After Triggers. (7) Assignment rules. (8) Auto-response rules. (9) Workflow rules (then re-evaluates if fields updated). (10) Processes (Process Builder). (11) Escalation rules. (12) Roll-up summary fields calculated. (13) Criteria-based sharing rules evaluated. (14) Commit to database. (15) Post-commit logic (emails, async jobs).

LWC is Salesforce's modern component framework based on web standards (HTML, JavaScript, CSS). Compared to Aura: (1) LWC uses native browser APIs and Web Components standards, making it faster. (2) LWC uses ES modules and modern JS syntax; Aura uses its own framework syntax. (3) LWC has a simpler, more standardised data binding model. (4) LWC has native support for reactive properties via @track, @api, @wire decorators. (5) LWC components load faster due to reduced framework overhead. Aura and LWC can interoperate — LWC components can be used inside Aura, but not vice versa.

Apex uses try-catch-finally blocks similar to Java. Common patterns: (1) Catch specific exception types (DmlException, QueryException, NullPointerException) before a generic catch(Exception e). (2) Use Database.SaveResult to handle partial DML success without throwing. (3) Log exception messages via custom objects or Platform Events. (4) Avoid catching generic exceptions at the top level unless re-throwing. Example: try { insert acct; } catch(DmlException e) { System.debug(e.getMessage()); }

Platform Events are Salesforce's implementation of the publish-subscribe pattern. They enable real-time, event-driven communication within Salesforce and with external systems. Use cases: (1) Decoupling processes — a trigger publishes an event; multiple subscribers react independently. (2) Real-time UI updates via LWC empStreamingApi. (3) Communicating between Salesforce orgs. (4) Integrating with external systems via Streaming API. Events are stored for 72 hours and can be replayed using Replay IDs.

with sharing: The class respects the running user's record-level access (sharing rules, OWD, role hierarchy). Users only see records they are entitled to. without sharing: The class ignores sharing rules and the user can access all records of the relevant objects. inherited sharing (newer): The class inherits the sharing mode of its caller. Best practice: Default to 'with sharing' for security. Use 'without sharing' only when necessary (e.g., system-level operations in a triggered context where a restricted user initiates the flow but system access is required).

A Profile is the primary security setting for a user. Every user has exactly one profile. It defines baseline access: object permissions, FLS, app settings, login hours, login IP ranges, and more. A Permission Set extends a user's access without changing their profile. A user can have multiple permission sets. This allows granular access for specific users without creating new profiles. Salesforce is moving toward a "Permission Set Everywhere" model, eventually deprecating many profile settings.

Salesforce record access is controlled at three levels: (1) Organisation-Wide Defaults (OWD): Sets the baseline level of access. Options: Public Read/Write, Public Read Only, Private, Controlled by Parent. (2) Role Hierarchy: Users higher in the hierarchy can access records owned by users below them (if "Grant Access Using Hierarchies" is enabled). (3) Sharing Rules, Manual Sharing, Apex Sharing: These open up access beyond OWDs for specific users or groups. Access can only be expanded beyond OWD, never restricted further.

Workflow Rules: Older automation tool. Limited to field updates, email alerts, tasks, and outbound messages. Only evaluates on record save. Cannot create related records or update records on related objects (with minor exceptions). Salesforce has announced retirement of Workflow Rules. Flow Builder: The recommended modern automation tool. Supports Screen Flows (user interaction), Record-Triggered Flows, Scheduled Flows, and Auto-launched Flows. Can create/update/delete any record, call Apex, post to Chatter, send custom notifications, and handle complex branching logic.

Master-Detail: A tightly-coupled relationship where the child record's lifecycle depends on the master. Deleting the master deletes all detail records (cascade delete). The master controls sharing and security of the detail. Supports Roll-Up Summary fields on the master. The master field is required on the child. Lookup: A loosely-coupled relationship. The lookup field is optional. Deleting the parent does not delete the child (you choose: clear field, restrict delete, or cascade delete). No Roll-Up Summary support. The child has its own OWD and sharing settings.

Field-Level Security controls which fields users can see (visible) or edit (editable) on records. It is configured through: (1) Profiles — in the field accessibility section or the field's setup page. (2) Permission Sets — grant additional field access beyond the profile. FLS applies everywhere the field appears: record detail pages, list views, related lists, reports, and Apex (when using 'with sharing'). Note: Page layout controls the field's display on a specific layout, but FLS is the authoritative security control.

Salesforce has four report types: (1) Tabular: Simple list of records with no grouping or totals. Good for exports or simple lists. Cannot be used as a dashboard source. (2) Summary: Records grouped by one or more fields with subtotals. Can be used in dashboards. (3) Matrix: Grouped by both rows and columns with summaries at intersections. Ideal for comparison reports. (4) Joined: Multiple blocks from different report types or objects in a single report. Useful for combining data from related objects.

When converting a Lead: (1) Salesforce creates or links to an existing Account based on the Company name. (2) A Contact is created from the Lead's personal information. (3) Optionally, an Opportunity is created. (4) The Lead record is marked as Converted (isConverted = true) and removed from the default Lead list views. (5) Activities associated with the Lead are transferred to the new records. Admin can configure Lead Conversion field mappings in Setup to control how Lead fields map to Account, Contact, and Opportunity fields.

An Approval Process is an automated workflow that routes records for approval through a multi-step sequence. Components: (1) Entry Criteria: Conditions that must be met for a record to enter the process. (2) Approver: The user(s) or queue that approves/rejects at each step. (3) Approval Actions: Actions taken when a record is approved (field update, email alert, task, outbound message). (4) Rejection Actions: Actions taken when rejected. (5) Recall Actions: Actions when a submitted record is recalled by the submitter. Records in an approval process are locked from editing by non-approvers.

Sandbox: A copy of a production org (full, partial, or metadata-only) used for development, testing, and training. Long-lived (refreshed periodically). Tied to a specific production org. Types: Developer, Developer Pro, Partial Copy, Full. Scratch Org: Part of Salesforce DX. A temporary, configurable, disposable org created from a project definition file. Not a copy of production. Designed for source-driven development, unit testing, and automation. Lives for 1–30 days. Ideal for CI/CD pipelines.

A Change Set is a collection of metadata components that can be deployed from one Salesforce org to another via a deployment connection. Limitations: (1) Only works between orgs connected via a Deployment Connection in Setup. (2) Cannot be used to deploy to a completely unrelated org. (3) Change sets cannot include all metadata types (e.g., standard fields, some settings). (4) Cannot delete metadata (only add/update). (5) No version control integration. For more robust deployments, Salesforce CLI (sf) or tools like Gearset/Copado are preferred.

Salesforce CPQ (Configure, Price, Quote) is a sales tool that helps sales teams generate accurate quotes quickly. It solves: (1) Configuration: Complex product catalogue management, bundles, and product rules. (2) Pricing: Automated pricing with discounts, price books, and pricing rules. (3) Quoting: Professional quote generation with PDF output, approval workflows, and contract generation. CPQ reduces manual errors, speeds up the sales cycle, and ensures pricing consistency across the entire sales team.

Product Rules automate product selection logic on a quote. Types: (1) Validation Rule: Prevents saving a quote if an invalid product combination is selected (e.g., a hardware product without a required service plan). (2) Alert Rule: Displays a warning message but allows saving. (3) Selection Rule: Automatically adds, removes, or hides products based on other product selections. (4) Filter Rule: Filters the product catalogue shown to the rep based on certain criteria. Product Rules use Conditions and Actions to define the trigger and the response.

Discount Schedules: Define tiered or block discounts based on quantity or term. They are applied directly to products and automatically calculate a discount when a rep enters a quantity. Example: 0–10 units = 0% discount, 11–50 units = 10% discount. Price Rules: More powerful and flexible formula-based pricing. They can inject calculated values into any quote or quote line field based on conditions. Example: If the customer is in a specific region and buys a bundle, apply a special price. Price Rules run in a defined sequence (Sort Order) and can reference quote fields, product fields, and custom conditions.

In Salesforce CPQ, a Quote is a child record of an Opportunity. It represents a pricing proposal for the customer. Key relationships: (1) An Opportunity can have multiple Quotes (e.g., different pricing scenarios). (2) Only one Quote can be the Primary Quote — syncing back to the Opportunity's products and amount. (3) A Quote contains Quote Lines (individual product/service line items with pricing). (4) When a Quote is approved and accepted, it can be converted to a Contract and Order through Salesforce Billing integration. The Quote PDF (generated from a Quote Template) is what the customer sees.

A Bundle in CPQ is a parent product that contains one or more component products (options). When a sales rep selects a bundle, a product configurator displays the available options. Key concepts: (1) Bundle Product: The parent/container product. (2) Option Groups: Logical groupings of component products (e.g., "Storage Options", "Support Plans"). (3) Product Options: Individual component products that can be optional (selected by rep) or required (automatically included). (4) Configuration Attributes: Shared fields that apply across all options in a bundle. Bundles enable complex product configurations while maintaining pricing accuracy.

Salesforce Billing is a managed package that extends CPQ to handle the quote-to-cash process end-to-end. Integration flow: (1) CPQ generates and approves a Quote. (2) The Quote is contracted (generating a Contract and Contracted Price records). (3) An Order is created from the Contract. (4) Salesforce Billing creates Invoices from Order products based on billing schedules. (5) Payments are processed and revenue is recognised. Key Billing concepts: Invoice runs, usage-based billing, payment gateways, revenue schedules, and dunning. CPQ handles the CPQ side (products, pricing, quoting); Billing handles the post-sale revenue side.