Salesforce interview questions

Salesforce is the world's leading cloud-based CRM (Customer Relationship Management) platform, used by companies to manage sales, service, marketing, and more. Core cloud products: Sales Cloud — Manage leads, opportunities, accounts, contacts, and sales pipelines. Automate follow-ups, forecast revenue. Service Cloud — Customer support: cases, knowledge base, live chat, omni-channel routing, field service. Marketing Cloud — Email campaigns, journeys, social listening, ad management, personalization. Commerce Cloud — B2C and B2B e-commerce storefronts with AI-powered recommendations. Experience Cloud (Community Cloud) — Build portals for partners, customers, and employees. Analytics Cloud (Tableau CRM / Einstein Analytics) — Embedded dashboards and AI-driven insights. Platform (Force.com) — Custom app development on Salesforce infrastructure using Apex, LWC, Visualforce. AppExchange — Marketplace with 7,000+ pre-built apps and integrations. Salesforce is structured around Objects (like database tables), Fields, Records, and Relationships. Standard objects include Account, Contact, Lead, Opportunity, Case. Admins and developers extend these with custom objects.

Salesforce Admin — works declaratively (no-code/low-code). Uses point-and-click tools: Process Builder, Flow, Validation Rules, Approval Processes, Reports, Dashboards, Profiles, Permission Sets. Manages users, data, security, and configurations. Salesforce Developer — writes code to extend the platform beyond declarative limits. Uses: - Apex (Java-like server-side language) - Lightning Web Components (LWC) — modern JavaScript UI framework - Visualforce — older page-based UI (legacy) - SOQL/SOSL — Salesforce query languages - REST/SOAP APIs and integrations - Triggers, batch jobs, schedulers Overlap: Both use Flow Builder (admins for simpler flows, developers for complex ones). Many orgs have developer-admins who do both. Key tool each uses: | Admin | Developer | |---|---| | Setup UI | VS Code + Salesforce DX | | Flow Builder | Apex IDE / Developer Console | | Object Manager | SOQL Editor | | AppExchange installs | Git + CI/CD pipelines | For interviews: understand declarative-first approach — always try to solve with Flow before writing Apex.

Objects in Salesforce are like database tables. Each object has fields (columns), records (rows), and relationships to other objects. Standard Objects — provided by Salesforce out of the box: - Account, Contact, Lead, Opportunity, Case, Task, Event, User, Product, Pricebook Custom Objects — created by admins/developers for business-specific data: - E.g., Invoice__c, Project__c, Training_Record__c - Custom objects always end with __c (API name) Key differences: | | Standard | Custom | |---|---|---| | Created by | Salesforce | Admins/Developers | | API name suffix | No suffix (Account) | __c (Invoice__c) | | Deletable | No | Yes | | Pre-built automation | Often | Must build | | AppExchange support | Yes | Yes | Custom fields on standard objects also use __c: Account.GST_Number__c Custom Metadata Types — like custom objects but for configuration data; deployed with code, not data. Custom Settings — similar, hierarchical (org/profile/user level). Tab: Each object can have a Tab (visible in App navigation). Custom objects need tabs created manually.

SOQL (Salesforce Object Query Language) — queries a single object and its relationships. Similar to SQL SELECT. SELECT Id, Name, Email FROM Contact WHERE AccountId = '001xx000003GYn1' Key features: - Query one object at a time (with sub-queries for related) - Use WHERE, ORDER BY, LIMIT, OFFSET, GROUP BY, HAVING - Relationship traversal: Contact.Account.Name (parent) or (SELECT Name FROM Contacts) (child) - All rows returned from one object tree SOSL (Salesforce Object Search Language) — full-text search across multiple objects simultaneously. FIND {Tata Consultancy} IN ALL FIELDS RETURNING Account(Name), Contact(FirstName, LastName), Lead(Company) Use SOQL when: - You know which object to query - You need filtering on specific fields - You need aggregate functions (COUNT, SUM, AVG) - Running DML operations based on results Use SOSL when: - You don't know which object contains the data - You want to search across multiple objects in one call - Full-text search (phone, name lookup across objects) - Building global search features Governor limits matter: SOQL queries are limited to 100 synchronous / 200 async per transaction. SOSL limited to 20. Always bulkify — never SOQL inside loops.

Apex is Salesforce's proprietary, strongly typed, object-oriented programming language that runs on Salesforce servers (multi-tenant cloud). Syntax is very similar to Java. Similarities to Java: - Classes, interfaces, inheritance, polymorphism - Strongly typed, compiled - Collections: List, Set, Map - Exception handling (try/catch/finally) - Access modifiers: public, private, protected, global Apex-specific differences: - SOQL/SOSL built into language: List<Contact> c = [SELECT Id FROM Contact]; - Built-in DML: insert, update, upsert, delete, undelete - Governor limits enforced at runtime (CPU time, SOQL queries, heap size, DML rows) - No file I/O, threading, or system calls - Test coverage is mandatory (75% minimum to deploy) - global keyword for code accessible across namespaces - Database.insert() vs insert — Database version returns SaveResults (partial success) Apex runs in triggers (before/after insert/update/delete), classes, REST/SOAP services, scheduled jobs, batch jobs, and future methods. Key Apex concepts for interviews: - Trigger best practice: one trigger per object, handler class pattern - Bulkification: handle 200 records at once, never SOQL in loops - Async: @future, Queueable, Schedulable, Batchable

Apex Triggers execute code before or after DML operations on Salesforce records. Trigger events: - before insert / before update / before delete - after insert / after update / after delete / after undelete Context variables: - Trigger.new — list of new records (insert, update) - Trigger.old — list of old records (update, delete) - Trigger.newMap / Trigger.oldMap — map by Id - Trigger.isInsert, Trigger.isUpdate, Trigger.isBefore, Trigger.isAfter Best practices: 1. One trigger per object — avoid multiple triggers with unpredictable order. 2. Handler class pattern — keep trigger thin, delegate to a handler class: trigger AccountTrigger on Account (before insert, after insert) { AccountTriggerHandler.handle(Trigger.operationType, Trigger.new, Trigger.oldMap); } 3. Bulkify — always write code to handle 200 records at once. Never SOQL or DML inside a loop. 4. Avoid recursive triggers — use a static boolean flag to prevent infinite loops. 5. Use before triggers for field modifications (no extra DML needed). 6. Use after triggers for operations requiring record Ids (e.g., creating child records). 7. Never hardcode IDs. 8. Write test classes with 75%+ coverage; test bulk scenarios (200 records).

Lightning Web Components (LWC) is Salesforce's modern UI framework built on Web Standards: Custom Elements, Shadow DOM, ES Modules, and Web Components. Aura Components (older) — Salesforce's proprietary framework from 2014. Uses its own event system, component library, and rendering model. More verbose. Key differences: | | LWC | Aura | |---|---|---| | Standards | Web Standards (Web Components) | Proprietary Salesforce framework | | Performance | Faster (native browser APIs) | Slower (abstraction overhead) | | Syntax | Standard HTML, JS, CSS | .cmp, .js, .css, .design, .svg | | Data binding | One-way by default | Two-way by default | | Events | Standard DOM events | Custom Aura events (complex) | | Testing | Jest (standard) | Aura test framework | | Learning curve | Easier (standard JS) | Steeper (framework-specific) | LWC file structure: myComponent/ myComponent.html — template with {property} binding myComponent.js — ES module with @api, @track, @wire decorators myComponent.css — scoped styles myComponent.js-meta.xml — deployment metadata Decorators: - @api — exposes property/method to parent - @track — reactive private property (objects/arrays) - @wire — wire Apex methods or UI APIs reactively Interoperability: LWC can be used inside Aura, but not vice versa. New development should use LWC.

Governor limits are enforced runtime limits that prevent any single tenant from monopolizing shared Salesforce infrastructure resources in the multi-tenant cloud. Why they exist: Salesforce runs thousands of orgs on shared servers. Without limits, one org's poorly written code could degrade performance for all tenants. Key limits (synchronous transactions): | Resource | Limit | |---|---| | SOQL queries | 100 | | SOQL rows returned | 50,000 | | DML statements | 150 | | DML rows processed | 10,000 | | CPU time | 10,000 ms | | Heap size | 6 MB | | Callouts (HTTP/web service) | 100 | | Future methods | 50 | Avoiding governor limit errors: 1. Bulkify code — handle collections, not single records 2. Move SOQL/DML outside loops — collect IDs, query once, process in map 3. Use @future / Queueable / Batch for async work 4. Query only fields you need (no SELECT *) 5. Use Maps for O(1) lookups instead of nested loops 6. Batch Apex for large data volumes (up to 50M records, 200 at a time) Common interview trap: "Where NOT to put SOQL" — never inside a for loop iterating over records. Extract IDs first, query once.

Salesforce Flow (Flow Builder) is the primary declarative automation tool. It allows admins and developers to automate processes, guide users through screens, and integrate with external systems — all without writing code. Types of Flows: - Screen Flow — guided UI for users (wizards, forms) - Record-Triggered Flow — triggers on record create/update/delete (replaces Workflow Rules and Process Builder) - Scheduled Flow — runs on a schedule for bulk operations - Autolaunched Flow — invoked from Apex, processes, or buttons (no user interaction) - Platform Event-Triggered Flow — responds to platform events When to use Flow (declarative-first principle): - Simple to medium field updates, email alerts, record creation - Multi-step screen processes with branching logic - Replace old Workflow Rules and Process Builder (both being retired) - Looping over related records and updating them When to write Apex instead: - Complex business logic needing multiple SOQL queries, maps, or algorithms - Callouts to external HTTP APIs - Batch processing of millions of records - Complex error handling or transactions - Logic that would exceed Flow's limits (2,000 loop iterations max) Rule of thumb: Try Flow first. Only reach for Apex when declarative tools can't accomplish the requirement or the logic becomes unmaintainable in Flow.

Profiles and Permission Sets control what users can see and do in Salesforce. Profile — every user has exactly one profile. It sets the baseline permissions: - Object-level: CRUD access (Create, Read, Edit, Delete) - Field-level security: visible / editable per field - App access, tab visibility, page layouts - Login hours, IP restrictions - System permissions (Modify All Data, View All Data, etc.) Common profiles: System Administrator, Standard User, Read Only, Minimum Access. Permission Sets — additive permissions layered on top of the profile. A user can have multiple. - Grant extra access without changing the profile - Reusable across users with different profiles - Example: Grant API access to select users who are otherwise Standard Users Permission Set Groups — bundle multiple permission sets for easier assignment. Best practices: - Use a restrictive base profile (e.g., Minimum Access) + permission sets to grant needs - Avoid modifying Standard profiles — clone them - Never use System Administrator profile for service accounts Field-Level Security (FLS): Controls which fields are visible/editable. Set at Profile and Permission Set level. Always check FLS in LWC/Apex when reading or writing fields — SOQL respects FLS for standard users.

Salesforce's core CRM data model: Account — represents a company or organization (B2B) or a person (B2C with Person Accounts enabled). All other records typically relate to an Account. Contact — an individual person at an Account. An Account has many Contacts (one-to-many). A Contact belongs to one Account (but can be related to multiple via Contact Roles on Opportunities). Lead — an unqualified prospect: a person or company that might become a customer. Leads are separate from Accounts/Contacts until converted. Lead Conversion — when a Lead is deemed qualified, it's "converted": - Creates an Account (or links to existing) - Creates a Contact from lead data - Optionally creates an Opportunity - Original Lead record is marked Converted (not deleted) Opportunity — a potential revenue deal. Belongs to an Account. Has a Sales Stage (Prospecting → Qualification → Proposal → Negotiation → Closed Won/Lost) and Close Date. Other key objects: - Task — a to-do item, linked to any record - Event — a calendar meeting/call - Case — a customer support request (linked to Account/Contact) - Product / Opportunity Line Item — products in a deal Typical sales process: Lead → Convert → Opportunity → Close Won → Account/Contact maintained for ongoing relationship.

Salesforce DX (Developer Experience) is Salesforce's modern development framework that brings software engineering best practices to Salesforce development. Core concepts: Scratch Orgs — ephemeral, disposable Salesforce environments. Spun up from source in minutes, used for development/testing, deleted when done. No shared developer sandboxes. Source-Driven Development — all metadata (Apex, LWC, objects, flows) lives in a Git repo as source files. Deploy from source, retrieve changes back. Replaces the old "change set" model. Salesforce CLI (sf / sfdx commands): - sf org create scratch — create scratch org - sf project deploy start — push source to org - sf project retrieve start — pull metadata from org - sf apex run — execute anonymous Apex - sf data query — run SOQL from terminal Benefits: - Version control for all metadata — commit, branch, PR review - CI/CD pipelines — automated testing and deployment - Package-based development — modular, versioned - Multiple developers on same project without conflicts - Second-generation managed packages (2GP) Org shapes: Dev Hub org licenses scratch orgs. Sandboxes still used for QA/UAT. VS Code + Salesforce Extension Pack is the standard IDE for SFDX development.