Interview Questions

A Sandbox is a copy of your Salesforce production environment used for development, testing, and training — without affecting live data or users.

Types of Sandbox:

Cloud Computing means accessing computing resources — servers, storage, databases, software — over the internet ("the cloud") instead of owning physical hardware.

Instead of buying and maintaining your own servers, you rent them from providers like AWS, Google Cloud, or Microsoft Azure and pay only for what you use.

Key benefits: Cost savings, scalability, accessibility from anywhere, automatic updates.

IaaS provides the raw infrastructure — virtual machines, storage, networking — over the internet. You manage the OS, middleware, and applications yourself; the provider manages the physical hardware.

Example: AWS EC2, Microsoft Azure VMs, Google Compute Engine.

Analogy: You rent an empty plot of land and build your own house on it.

PaaS provides a ready-made platform — runtime, middleware, database — so developers can build and deploy applications without worrying about the underlying infrastructure.

Example: Salesforce Platform, Google App Engine, Heroku.

Analogy: You rent a fully built house with utilities already set up — you just furnish it.

SaaS delivers fully built, ready-to-use software over the internet. No installation or maintenance needed — just log in and use.

Example: Salesforce CRM, Gmail, Dropbox, Microsoft 365.

Analogy: You stay in a hotel — everything is managed for you, you just use it.

A Junction Object is a custom object with two Master-Detail relationships used to create a Many-to-Many relationship between two objects.

Example:

• A Student can enroll in many Courses
• A Course can have many Students
• Solution: Create a Junction Object called Enrollment with Master-Detail to both Student and Course.

Key points:

• It inherits sharing from both parent objects
• Deleting either parent deletes the junction record
• You can add custom fields on the junction object for extra context (e.g., Enrollment Date, Grade)

Simple rule: Profile = permissions, Role = visibility.

Salesforce provides 5 main ways to share records:

Note: Teams (Account Teams, Opportunity Teams) and Territory Management are also sharing mechanisms used in specific contexts.

Manual Sharing allows a record owner or administrator to share a specific record with a specific user, role, or group on a case-by-case basis.

• Done via the "Sharing" button on the record detail page
• Grants Read or Read/Write access
• Not scalable — works for one-off exceptions
• Available only when OWD is set to Private or Public Read Only
• Can be removed by the owner or admin

Use when: A specific user needs access to one record, and no automated rule covers that case.

Apex Sharing (Programmatic Sharing) lets developers use Apex code to share records based on complex business logic that cannot be handled by Sharing Rules or Manual Sharing.

Done by inserting records into the Share object (e.g., AccountShare, OpportunityShare, or MyObject__Share for custom objects).

AccountShare share = new AccountShare();
share.AccountId = accountId;
share.UserOrGroupId = userId;
share.AccountAccessLevel = 'Edit';
share.RowCause = Schema.AccountShare.RowCause.Manual;
insert share;

Use when: Sharing logic depends on dynamic conditions, complex relationships, or runtime data that declarative tools cannot handle.

Rule of thumb: Always try Flow first. Use Apex only when Flow cannot handle it.

1. Use one Flow per object/trigger — avoid multiple flows on the same object to control execution order
2. Use subflows — break large flows into reusable smaller ones
3. Bulkify your Flow — avoid SOQL/DML inside loops; use collections
4. Add Fault Paths — always handle errors gracefully
5. Use descriptive labels — name elements clearly for maintainability
6. Avoid hard-coded IDs — use Custom Labels or Custom Metadata instead
7. Test with Flow debugger — use built-in debug tools before deploying
8. Use Before-Save flows for field updates — they're faster and don't consume DML
9. Version control — keep older versions; don't delete them immediately
10. Document your Flow — add descriptions and notes inside the Flow canvas

Apex is Salesforce's proprietary, Java-like programming language that runs on the Salesforce platform server. It lets developers write complex business logic, database operations, and integrations.

Use Apex over Flow when:

• You need to make HTTP callouts to external APIs
• You need complex data manipulation or algorithms
• You need to handle large data volumes efficiently (Batch Apex)
• Your logic requires precise error handling and transactions
• You're building reusable utility classes or trigger frameworks
• Flow's declarative tools simply cannot achieve the required logic

• Bulkify all code — write code that handles collections, not single records
• Avoid SOQL/DML inside loops — query/insert outside loops, use lists
• Use Trigger Handler pattern — keep triggers thin; put logic in handler classes
• Write test classes — minimum 75% code coverage; aim for 90%+
• Use @TestSetup — create shared test data efficiently
• Follow Governor Limits — always be aware of SOQL, DML, CPU limits
• Use Custom Metadata / Custom Settings — avoid hard-coded values
• Use with sharing — respect user's sharing rules unless explicitly needed otherwise
• Handle exceptions — use try-catch and log errors
• Write modular code — separate concerns; one class, one responsibility

A Trigger Framework is a structured, reusable architecture for managing triggers consistently across an entire Salesforce org. It solves problems like: multiple triggers per object, uncontrolled execution order, and code duplication.

Common frameworks available:

What a good framework provides:

• One trigger per object
• Enable/disable triggers via Custom Metadata
• Recursion prevention (stops infinite loops)
• Consistent structure across all triggers

Lightning Data Service (LDS) is a built-in Salesforce service that allows LWC and Aura components to read, create, edit, and delete records without writing any Apex code.

Key benefits:

• No Apex needed for standard CRUD operations
• Automatic caching — data is shared across components on the same page
• Reactive — components automatically refresh when data changes
• Respects FLS and sharing rules automatically

In LWC, LDS is used via:

// Wire to get record
import { LightningElement, wire } from 'lwc';
import { getRecord } from 'lightning/uiRecordApi';

@wire(getRecord, { recordId: '$recordId', fields: ['Account.Name'] })
account;

Or using base components:

<lightning-record-form record-id={recordId} object-api-name="Account" />

Integration patterns define how Salesforce communicates with external systems. Choosing the right pattern depends on timing, data volume, and direction.

Main Integration Patterns:

1. Request & Reply (Synchronous)

• Salesforce calls external system and waits for a response
• Use: Real-time data lookup (credit check, address validation)
• Tool: REST/SOAP callout from Apex

2. Fire & Forget (Asynchronous)

• Salesforce sends data and doesn't wait for a response
• Use: Sending notifications, logging to external systems
• Tool: @future, Platform Events, Outbound Messages

3. Batch Data Synchronization

• Bulk data moved between systems on a schedule
• Use: Nightly sync of orders, products, or customers
• Tool: Batch Apex, ETL tools (MuleSoft, Informatica)

4. Remote Call-In

• External system calls into Salesforce to read/write data
• Use: External app creating leads or updating records in Salesforce
• Tool: Salesforce REST/SOAP API, Bulk API

5. UI Update Based on Data Change (Event-Driven)

• System reacts when data changes, pushing updates automatically
• Use: Real-time dashboards, notifications
• Tool: Platform Events, Streaming API, Change Data Capture (CDC)