Home › Fresher

125 Salesforce Fresher Interview Questions & Answers 2026

📅 Fresher

🌱 Fresher Interview Prep 2026

Top 125 Salesforce Fresher Interview Questions & Answers 2026

How To Prepare + 125 Must-Know Questions With Detailed Answers — Basics to Apex, LWC & Integration

125Questions

7Sections

FresherLevel 🟢

100%Free

⚡ Complete Index — All 125 Questions

🎯

How Freshers Should Prepare

Focus areas before you touch a single interview question

Fresher interviews test fundamentals and communication — not architecture skills. Here's exactly where to focus your limited prep time.

🔑 Priority Order

1) Salesforce basics (Objects, Fields, Relationships) 2) Admin fundamentals (Profiles, Permission Sets, OWD, Sharing Rules) 3) Flow Builder (asked in almost every fresher interview now) 4) Apex basics (Triggers, SOQL, Governor Limits) 5) LWC basics (decorators, parent-child communication)

💡 What Actually Separates a 9/10 Fresher

Not memorizing more definitions — knowing the "why." Why does a Trigger use before-insert vs after-insert? Why does OWD matter before Role Hierarchy? Have 1-2 hands-on projects (even a simple Developer Org build) you can walk through confidently. Browse our complete list of free Salesforce courses to build that hands-on foundation before your interview. And practice saying answers out loud in 30-60 seconds — most freshers lose points on rambling, not on knowledge gaps.

🧱

Salesforce Basics

Q1–Q15 · Objects, fields, relationships, and page setup

Q001🟢

What is Salesforce and what is CRM?

Salesforce is a cloud-based CRM platform. CRM means software that helps a business manage its interactions with current and potential customers.

🔑 Key Points

CRM stores contact details, tracks sales opportunities, manages support cases, and automates business processes around all of this. Salesforce's advantage over traditional CRM: entirely cloud-based (no on-premise servers), highly customizable using clicks and code, and constantly updated with 3 releases a year.

🌍 Simple Way to Explain It

Think of it as a giant digital notebook shared across a company — Sales sees every deal, Support sees every customer issue, Marketing sees every campaign response, all connected to the same customer record instead of scattered across spreadsheets and inboxes.

🎤 "Salesforce is a cloud-based CRM platform that helps businesses manage and automate their interactions with customers across sales, service, and marketing."

Q002🟢

What is the difference between Salesforce Classic and Lightning Experience?

Classic is the older, table-based interface. Lightning Experience is the modern, component-based UI built on Lightning Web Components and Aura.

🔑 Key Points

Lightning is faster and more visual, supports Kanban views, Flow-based automation UI, and modern dashboards. Salesforce pushes ALL new features into Lightning only — Classic is considered legacy and is being phased out. If you're learning today, learn Lightning; Classic knowledge is only relevant for legacy org support.

🌍 Interview Tip

If asked "have you worked in Classic?" as a fresher, it's completely fine to say you trained on Lightning — that's the current standard and what every new implementation uses.

🎤 "Lightning Experience is Salesforce's modern, component-based UI that replaced the older table-based Classic interface, and it's where all new features are built."

Q003🟢

What are Objects in Salesforce? Standard vs Custom Objects?

An Object is like a table in a database — it defines a type of record with a set of fields. Standard Objects come pre-built (Account, Contact, Opportunity, Lead, Case). Custom Objects are ones you create for your business needs.

🔑 Key Points

Custom Objects always end with "__c" in their API name (e.g., Project__c). Standard Objects don't have this suffix. Both can have custom fields added to them. Custom Objects need their own tab, page layout, and security settings configured — they don't come with anything built-in like Standard Objects do.

🌍 Example

A company selling software uses standard Account and Opportunity objects for sales. If they also want to track internal "Projects" for implementation work, they'd build a custom object called Project__c since Salesforce has no standard object for that.

🎤 "Objects are like database tables — Standard Objects (Account, Contact, Opportunity) come built-in, Custom Objects (ending in __c) are created for business-specific needs."

Q004🟢

What is a Field? Name different field types.

A Field is a single piece of data stored on an Object — like a column in a database table.

🔑 Key Points

Common field types: Text, Number, Date, Date/Time, Checkbox, Picklist, Multi-Select Picklist, Currency, Email, Phone, URL, Formula (calculated, read-only), Lookup (loose relationship), and Master-Detail (tight relationship). Each field type has different storage behavior and validation rules that come with it automatically (e.g., Email fields validate format automatically).

🌍 Example

On the Contact object: Name is a Text field, Email is an Email field, Birthdate is a Date field, and Account Name is a Lookup field pointing to the Account object.

🎤 "A Field stores a single piece of data on an Object — common types include Text, Number, Picklist, Formula, and relationship fields like Lookup and Master-Detail."

Q005🟢

What is a Record?

A Record is a single row of data within an Object — one specific instance of that object.

🔑 Key Points

Every record has a unique 15/18-character Record ID. Records have system fields like CreatedDate, CreatedById, LastModifiedDate automatically tracked by Salesforce. Records can be related to other records through Lookup or Master-Detail relationships.

🌍 Example

"Acme Corp" is a single Account record. "John Smith" is a single Contact record related to that Account.

🎤 "A Record is a single instance of data within an Object — essentially one row in that object's table."

Q006🟠

What is the difference between a Lookup and Master-Detail relationship?

A Lookup relationship loosely links two objects — the child can exist independently. A Master-Detail relationship tightly couples two objects — the child cannot exist without a parent.

🔑 Key Points

Lookup: deleting the parent does NOT delete the child; child record's OWD/sharing is independent. Master-Detail: child inherits the parent's sharing and security settings; deleting the parent deletes ALL child records; Master-Detail field is required (can't be blank) unless made optional at creation; Roll-Up Summary fields only work with Master-Detail.

🌍 Example

Contact-to-Account is a Lookup (deleting an Account doesn't delete its Contacts). A custom "Invoice Line Item" to "Invoice" would typically be Master-Detail — a line item can't exist without its parent invoice.

🎤 "Lookup is a loose relationship where the child can exist independently; Master-Detail is a tight relationship where the child inherits security from the parent and is deleted along with it."

Q007🟠

What happens to child records when a Master-Detail parent is deleted?

All child records are deleted along with the parent record — they go to the Recycle Bin together, and if the parent is restored, the children are restored too.

🔑 Key Points

This is a key difference from Lookup relationships, where child records survive parent deletion (their lookup field just goes blank, or the delete is blocked if the org has "delete restriction" configured). This cascade-delete behavior is why Master-Detail is used when a child record has no meaning without its parent.

🌍 Example

If "Invoice" is the master and "Invoice Line Item" is the detail, deleting an Invoice deletes all its Line Items too — makes sense because a line item without an invoice doesn't mean anything.

🎤 "In a Master-Detail relationship, deleting the parent record cascades and deletes all related child records — they're restored together too if undone from the Recycle Bin."

Q008🟠

What is a Junction Object? Why is it used?

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

🔑 Key Points

Standard relationships (Lookup, Master-Detail) only support one-to-many. When you need many-to-many, you create a junction object sitting in the middle with a Master-Detail relationship to each of the two objects being connected.

🌍 Example

A Student can enroll in many Courses, and a Course can have many Students — classic many-to-many. Solution: create "Enrollment__c" as a junction object with Master-Detail to both Student__c and Course__c.

🎤 "A Junction Object uses two Master-Detail relationships to enable many-to-many relationships between two objects, since standard relationships only support one-to-many."

Q009🟠

What is a Roll-Up Summary field? On which relationship does it work?

A Roll-Up Summary field on a parent record calculates a value (SUM, COUNT, MIN, MAX) based on related child records. It only works on Master-Detail relationships.

🔑 Key Points

It does NOT work on standard Lookup relationships — for that, you'd need Flow or Apex triggers to achieve a similar rollup effect. Roll-Up Summary fields auto-update in real time whenever a child record is created, updated, or deleted.

🌍 Example

On an Invoice (master) with Invoice Line Items (detail), a Roll-Up Summary field could show "Total Amount" = SUM of all Line Item amounts, automatically recalculating as line items are added or removed.

🎤 "A Roll-Up Summary field aggregates values from child records onto the parent — SUM, COUNT, MIN, or MAX — but it only works when the relationship is Master-Detail."

Q010🟢

What are Page Layouts?

Page Layouts control what fields, related lists, and buttons appear on a record's detail and edit pages.

🔑 Key Points

Different Profiles or Record Types can be assigned different Page Layouts, so different users see different arrangements of the same object. Page Layout does NOT control field-level security — that's separate and always takes priority over what the Page Layout shows.

🌍 Example

A Sales Rep's Opportunity Page Layout might show Amount, Close Date, and Stage prominently. A Finance user's layout for the same object might instead surface Invoice Number and Payment Terms.

🎤 "Page Layouts control the visual arrangement of fields, related lists, and buttons on a record page — different Profiles or Record Types can have different layouts."

Q011🟠

What is the difference between Page Layout and Record Type?

Page Layout controls the visual arrangement of fields and related lists. Record Type controls which picklist values are available and can drive a different business process for the same object.

🔑 Key Points

Record Types are assigned per Profile, and each Record Type can be linked to a specific Page Layout. This means Record Type indirectly determines layout too — but its main job is controlling picklist value sets and business processes (like different Support Processes for Cases).

🌍 Example

Two Opportunity Record Types — "Enterprise Deal" and "Small Business Deal" — could each have different Stage picklist values available and different Page Layouts showing relevant fields for that deal type.

🎤 "Page Layout arranges fields visually; Record Type controls picklist values and business process — and each Record Type is usually linked to a specific Page Layout."

Q012🟠

What is a Validation Rule?

A Validation Rule is a formula-based rule that checks data before it is saved, and blocks the save with an error message if the formula evaluates to true.

🔑 Key Points

Validation Rules fire on both insert AND update (unlike some Trigger contexts). They run after all field-level validations but before the record is committed. You can set the error to display on a specific field or at the top of the page. Multiple validation rules can exist per object — all are evaluated on save.

🌍 Example

Preventing an Opportunity Close Date in the past: formula CloseDate < TODAY() → shows error "Close Date cannot be in the past" and blocks the save.

🎤 "A Validation Rule is a formula that blocks a record save with an error message when a specific condition is true — used to enforce data quality."

Q013🟠

What is the difference between a Formula field and a Validation Rule?

A Formula field calculates and displays a value automatically based on other fields (read-only, always recalculated). A Validation Rule doesn't display anything — it only blocks a save if a condition is violated.

🔑 Key Points

Formula fields are visible on the record and update live even without saving (in most contexts). Validation Rules have no visible value — their only output is an error message when triggered. Both use similar formula syntax, but their purpose is completely different: one displays data, the other enforces data quality.

🌍 Example

A Formula field "Days Until Close" = CloseDate - TODAY() displays a number. A Validation Rule on the same object might block saving if CloseDate is in the past — they can coexist on the same object serving different purposes.

🎤 "Formula fields calculate and display a value; Validation Rules only block saves with an error message — they don't display anything on the record."

Q014🟢

What is an App in Salesforce (Lightning App)?

A Lightning App is a collection of tabs, objects, and branding grouped together for a specific business function, like "Sales" or "Service."

🔑 Key Points

Apps give users a focused navigation experience for their role — a Sales user opens the "Sales" app and sees Leads, Opportunities, Accounts tabs relevant to selling. Apps can be assigned to specific Profiles so users only see apps relevant to their job.

🌍 Example

The Service Console app groups Case, Knowledge, and Omni-Channel related tabs for support agents, while the Sales app groups Leads, Opportunities, and Accounts for sales reps.

🎤 "A Lightning App groups tabs and objects together for a specific business function, giving users a focused, role-relevant navigation experience."

Q015🟢

What are Tabs in Salesforce?

Tabs are UI elements that give users access to view a particular object's data — clicking the "Accounts" tab takes you to the Accounts list view.

🔑 Key Points

Tabs can represent Standard Objects, Custom Objects, or even a Visualforce/Lightning page. Tab visibility can be controlled per Profile (Tab Settings) independent of object-level permissions — meaning a user might have object access but the tab hidden from their navigation.

🌍 Example

A custom object "Project__c" needs a Tab created for it before users can navigate to it directly from the App Launcher or navigation bar — otherwise they can only reach Project records through related lists.

🎤 "Tabs are the UI elements that let users navigate directly to an object's records — they can be shown or hidden per Profile independent of object permissions."

🔐

Admin & Security

Q16–Q35 · OWD, sharing, profiles, and org security

Q016🟠

What is Organization-Wide Default (OWD)?

OWD is the baseline, most restrictive level of record access for an object across the entire org — defining what a user can see if they are not the owner and have no other access granted.

🔑 Key Points

OWD is the starting point of the sharing model. Role Hierarchy and Sharing Rules can only OPEN UP access beyond OWD — they can never restrict it further. Set separately for each object. Changing OWD to more restrictive can trigger a lengthy recalculation job in large orgs.

🌍 Example

If Opportunity OWD is Private, a Sales Rep can only see their own Opportunities by default — until Role Hierarchy or a Sharing Rule grants their manager or team broader visibility.

🎤 "OWD sets the baseline, most restrictive record access level per object — Role Hierarchy and Sharing Rules can only expand access from there, never restrict it further."

Q017🟢

What are the OWD access levels?

Private (only owner and users above in role hierarchy see it), Public Read Only (everyone views, only owner/admins edit), and Public Read/Write (everyone views and edits).

🔑 Key Points

Some objects also support "Controlled by Parent" (child inherits access from a Master-Detail parent) and "Public Read/Write/Transfer" (Leads and Cases only — allows record ownership transfer too).

🌍 Example

Contact OWD is often set to "Controlled by Parent" since Contacts typically inherit their sharing from the related Account.

🎤 "OWD access levels are Private, Public Read Only, and Public Read/Write — with Controlled by Parent and Public Read/Write/Transfer available for specific objects."

Q018🟠

What is a Role Hierarchy and how does it affect record access?

Role Hierarchy is a structure mirroring an organization's reporting structure. If OWD is Private, users higher in the hierarchy automatically get access to records owned by users below them.

🔑 Key Points

This is how a Sales Manager can see their team's Opportunities without needing an explicit Sharing Rule. Role Hierarchy access only flows UPWARD (managers see subordinates' records, not the reverse). This behavior can be disabled per object using "Grant Access Using Hierarchies" checkbox on Sharing Settings (only for custom objects).

🌍 Example

A Regional Sales Manager role sits above 5 Sales Rep roles in the hierarchy — the manager automatically sees all Opportunities owned by those 5 reps, even with OWD set to Private.

🎤 "Role Hierarchy mirrors the reporting structure, and when OWD is Private, users automatically inherit visibility into records owned by anyone below them in the hierarchy."

Q019🟠

What is a Sharing Rule and when do you need one?

A Sharing Rule opens up record access beyond what OWD and Role Hierarchy provide, without changing a user's Profile permissions.

🔑 Key Points

You need one when a group of users (not in the same reporting line) needs access to records they don't own. Two types: Owner-based (based on who owns the record) and Criteria-based (based on field values on the record, regardless of owner). Sharing Rules can only grant access — never restrict it below OWD.

🌍 Example

All Leads owned by the Marketing team need to be visible to the entire Sales team (who are in a completely different branch of the Role Hierarchy) — a Sharing Rule handles this cleanly.

🎤 "Sharing Rules extend record access beyond OWD and Role Hierarchy — needed when groups outside the normal reporting line require visibility into records they don't own."

Q020🟠

What is the difference between Profile and Permission Set?

A Profile is mandatory — every user has exactly one. It defines baseline object/field permissions, page layouts, and login access. A Permission Set is optional and additive — a user can have multiple, used to grant extra access on top of their Profile.

🔑 Key Points

Best practice (Salesforce's own recommendation): keep Profiles minimal (login settings, page layout assignment) and use Permission Sets for granular object/field access — this scales better as an org grows and reduces the number of Profiles you need to maintain.

🌍 Example

All Sales Reps share the "Standard User" Profile, but a few reps who also handle billing get an additional "Billing Access" Permission Set granting them extra object permissions — without needing a separate Profile just for those few users.

🎤 "Profile is the mandatory, single baseline of permissions every user has; Permission Sets are optional, additive grants — best practice is minimal Profiles plus Permission Sets for flexibility."

Q021🟢

Can a user have more than one Profile?

No. Every user has exactly one Profile at a time.

🔑 Key Points

If a user needs more access, you use Permission Sets or Permission Set Groups instead of switching or stacking Profiles. An admin CAN change which single Profile a user has assigned, but never assign two simultaneously.

🌍 Common Confusion

Freshers often think you can "add" a second Profile the way you add a Permission Set — this is a common trick question, so remember: one Profile only, unlimited Permission Sets.

🎤 "No — every user has exactly one Profile. Additional access is granted through Permission Sets, not multiple Profiles."

Q022🟠

What is Field-Level Security and where is it set?

Field-Level Security controls whether a specific field is visible, editable, or hidden for a user, regardless of what the Page Layout shows.

🔑 Key Points

It's set at the Profile or Permission Set level and ALWAYS overrides Page Layout visibility — if FLS hides a field, it won't show even if the Page Layout includes it. This is the actual security enforcement layer; Page Layout is just cosmetic arrangement.

🌍 Example

A "Salary__c" field on Contact might be on the Page Layout, but Field-Level Security hides it from all Profiles except HR — so most users simply never see that field even though it's technically on their layout.

🎤 "Field-Level Security, set at the Profile or Permission Set level, controls actual field visibility and editability — and it always overrides whatever the Page Layout displays."

Q023🟠

What is the difference between Profile-level and Permission Set-level object access?

They function the same way technically — both can grant Create, Read, Edit, Delete (CRED) permissions on an object. The difference is Profile-level is the mandatory baseline, while Permission Set-level is additive and flexible.

🔑 Key Points

Permission Sets can be easily assigned or removed without touching the Profile, making access changes safer and more auditable. If both Profile and Permission Set grant access to the same object, the MOST permissive setting wins (permissions are additive, never restrictive).

🌍 Example

Profile grants Read-only on a custom object. A Permission Set assigned to specific users grants Edit on the same object. Those specific users end up with Edit access (the more permissive wins).

🎤 "Both grant object CRED permissions the same way — but Permission Set access is additive on top of Profile, and when they differ, the most permissive setting applies."

Q024🟠

What is a Permission Set Group?

A Permission Set Group bundles multiple Permission Sets into a single assignable unit.

🔑 Key Points

Instead of assigning 5 separate Permission Sets to a user one by one, you assign one group that contains all 5. You can also apply "Muting Permission Sets" within a group to remove specific permissions from the bundle for exceptions — without breaking apart the whole group.

🌍 Example

A "Sales Manager Bundle" Permission Set Group might combine "Opportunity Advanced Access," "Report Builder Access," and "Team Dashboard Access" Permission Sets into one clickable assignment.

🎤 "A Permission Set Group bundles multiple Permission Sets together so they can be assigned to a user as one unit instead of individually."

Q025🟠

What are Public Groups used for?

Public Groups combine users, roles, and/or other groups into a single named group, mainly used as a target for Sharing Rules or for setting up folder/report visibility.

🔑 Key Points

Public Groups save admins from having to list individual users repeatedly across multiple Sharing Rules, Report Folders, or Dashboard permissions. They can be nested (a group can include another group).

🌍 Example

Instead of adding 15 individual Support agents to a Sharing Rule, an admin creates a "Support Team" Public Group containing all 15, then references that one group in the Sharing Rule.

🎤 "Public Groups bundle users, roles, or other groups so they can be referenced as one unit in Sharing Rules or folder permissions, instead of listing individuals repeatedly."

Q026🟠

What is Manual Sharing?

Manual Sharing lets a record owner or someone with full access share an individual record with a specific user or group directly from the record page, without needing a formal Sharing Rule.

🔑 Key Points

It's a one-off, record-level share — not scalable for bulk sharing needs (that's what Sharing Rules are for). Only available if OWD for the object is more restrictive than Public Read/Write (no point manually sharing something already open to everyone).

🌍 Example

A Sales Rep wants a colleague in a different team to temporarily view one specific high-value Opportunity — they click "Sharing" on that record and manually add the colleague, rather than creating an org-wide Sharing Rule for a single record.

🎤 "Manual Sharing is a one-off way to share a single record with a specific user directly from the record page, used for exceptions rather than broad access patterns."

Q027🟠

What is the difference between Role and Profile?

Profile controls what a user can DO (object/field permissions, app access, login settings). Role controls what RECORDS a user can see through the Role Hierarchy, mainly relevant when OWD is Private.

🔑 Key Points

A user needs both — Profile for permissions, Role for hierarchy-based visibility. A user can technically have no Role assigned (common for Portal/Community users), but then they get no hierarchy-based record access at all.

🌍 Example

Two Sales Reps might share the exact same Profile (same permissions to do things) but have different Roles (one reports to Manager A, another to Manager B) — meaning their managers see different sets of records despite the reps having identical permissions.

🎤 "Profile controls what actions a user can perform, while Role controls what records they can see via the hierarchy — a user typically needs both, and they serve completely different purposes."

Q028🟠

What are Login Hours and Login IP Ranges?

These are Profile-level security settings. Login Hours restrict what time of day a user can log in. Login IP Ranges restrict login access to specific IP addresses.

🔑 Key Points

If a user tries logging in outside Login Hours, they're logged out automatically (or blocked from logging in, depending on config). Login IP Ranges: if set at the Profile level and the user logs in from outside those IPs, they may be blocked entirely or required to do additional identity verification depending on org settings.

🌍 Example

A company might restrict Support agent logins to 8am-8pm only, and Finance Profile logins to only the office's IP range for extra security around sensitive financial data.

🎤 "Login Hours restrict what time a user can access Salesforce, and Login IP Ranges restrict which networks they can log in from — both set at the Profile level."

Q029🟢

What is Two-Factor Authentication in Salesforce?

Two-Factor Authentication (2FA) requires users to verify their identity with a second factor (like a mobile authenticator app code) in addition to their username/password.

🔑 Key Points

Salesforce mandates 2FA for all direct UI logins as of recent releases — it's no longer optional for most orgs. Common second factors: Salesforce Authenticator app, third-party TOTP apps (Google Authenticator), or security keys.

🌍 Why It Matters

Even if a user's password is stolen (phishing, data breach), 2FA prevents unauthorized login since the attacker doesn't have the second factor.

🎤 "Two-Factor Authentication requires a second identity verification step beyond password — Salesforce now mandates this for direct UI logins to strengthen account security."

Q030🟠

What is a Queue and when do you use it?

A Queue is a holding area for records (commonly Leads or Cases) that are not assigned to a specific individual yet, but to a team. Any member of the Queue can pick up and work on records inside it.

🔑 Key Points

Queues support multiple objects (standard and custom) as long as the object allows queue ownership. Queue membership can include Users, Roles, Public Groups, or Roles-and-Subordinates. Common use case: support ticket routing (a "Tier 1 Support" queue) or lead distribution (a "Unassigned Leads" queue).

🌍 Example

Incoming Cases from a Web-to-Case form land in a "General Support" Queue. Any of the 5 agents who are members of that Queue can claim and work the case.

🎤 "A Queue is a team-level holding area for unassigned records — any queue member can claim and work records from it, commonly used for Lead distribution and Case routing."

Q031🟠

What is Delegated Administration?

Delegated Administration lets you grant limited admin-like permissions to non-admin users — such as managing users of a specific Profile, or managing specific custom objects — without giving them full System Administrator access.

🔑 Key Points

Configured under Setup → Delegated Administration. You define which Roles/Profiles the delegate can manage, and which permissions they get (reset passwords, create/edit users, manage specific custom objects). This follows the principle of least privilege — reduces risk vs handing out full Admin access.

🌍 Example

An HR team lead is given Delegated Admin rights to create and manage users with the "Standard Employee" Profile, but has zero visibility into System Administrator-level settings like Apex code or security controls.

🎤 "Delegated Administration grants limited, scoped admin permissions to non-admin users — like managing a specific group of users — without exposing full System Administrator access."

Q032🟠

What are the differences between Salesforce Editions?

Editions differ mainly in feature availability and limits. Essentials is the most basic. Professional adds customization but limits API access. Enterprise unlocks full API access, Role Hierarchy, and advanced automation. Unlimited includes everything Enterprise has plus higher limits and premium support.

🔑 Key Points

Enterprise Edition is the most common for mid-to-large businesses since it's the first tier with full API access — meaning custom integrations, most AppExchange apps, and Apex/LWC development typically require at least Enterprise Edition.

🌍 Interview Tip

You don't need to memorize exact feature-by-feature differences — knowing that Enterprise is the "developer-friendly, full API access" tier is usually enough at fresher level.

🎤 "Editions scale from Essentials (basic) through Professional, Enterprise (full API access, most common for development), to Unlimited (highest limits and support)."

Q033🟠

What is a Sandbox? Name the types.

A Sandbox is a copy of your production org used for development, testing, and training without affecting live data. Types include Developer Sandbox, Developer Pro Sandbox, Partial Copy Sandbox, and Full Copy Sandbox.

🔑 Key Points

Each type differs in storage limit and whether/how much production DATA it copies (metadata is always copied in all types). Refresh intervals also differ — Developer Sandboxes can refresh daily, while Full Copy Sandboxes typically refresh only every 29 days.

🌍 Example

A developer building and testing a new Flow would typically use a Developer Sandbox (fast, cheap to refresh). Before a major release, the team might do final UAT testing in a Full Copy Sandbox that mirrors production data exactly.

🎤 "A Sandbox is an isolated copy of production for safe development and testing — types range from Developer (metadata only) to Full Copy (metadata plus all production data)."

Q034🔴

What's the difference between Full Copy Sandbox and Developer Sandbox?

A Developer Sandbox copies only metadata (no production data) and has a small storage limit — good for individual development. A Full Copy Sandbox copies both metadata AND all production data, has much larger storage, and is used for full-scale testing.

🔑 Key Points

Developer Sandbox: typically a few hundred MB storage, refreshable daily — ideal for quick individual dev work. Full Copy Sandbox: matches production storage size, refreshable roughly every 29 days — used for UAT, performance testing, and staging before major releases since it behaves exactly like production.

🌍 Example

A developer wants to quickly test a new trigger — they use their personal Developer Sandbox. Before a company-wide release, the QA team runs full regression testing in a Full Copy Sandbox because it has real customer data volumes to catch performance issues that wouldn't show up with tiny test data.

🎤 "Developer Sandbox is metadata-only with small storage for quick individual dev work; Full Copy Sandbox mirrors production data and storage exactly, used for UAT and performance testing."

Q035🟠

What is Change Set used for?

A Change Set is a native Salesforce tool used to migrate metadata (like new fields, objects, Flows, or Apex classes) from one org to another connected org — typically Sandbox to Production — without needing external tools.

🔑 Key Points

Change Sets only work between orgs that are explicitly connected (like a Sandbox linked to its Production org) — you can't Change Set between two unrelated orgs. Outbound Change Set is created in the source org; Inbound Change Set is deployed in the target org. Many teams now use Salesforce CLI/DevOps Center for more advanced deployment needs, but Change Sets remain common for simpler admin-driven deployments.

🌍 Example

An admin builds a new Validation Rule and a custom field in a Sandbox, tests it, then creates an Outbound Change Set containing those components and uploads it to Production for deployment.

🎤 "A Change Set is Salesforce's native tool for migrating metadata between connected orgs, most commonly Sandbox to Production, without needing external CI/CD tools."

🗂️

Data Management

Q36–Q50 · Import, export, reports and dashboards

Q036🟠

What is the difference between Data Import Wizard and Data Loader?

Data Import Wizard is a simple browser-based tool for smaller imports (up to 50,000 records) with a guided UI. Data Loader is a standalone desktop app (or CLI) for bulk operations up to 5 million records, supporting insert/update/upsert/delete/export.

🔑 Key Points

Import Wizard: limited objects (Accounts, Contacts, Leads, Custom Objects), no delete or export support, good for one-time small imports. Data Loader: works on any object, supports scheduling, and can be run in command-line/batch mode for automation.

🌍 XYZ Company / Example

An admin doing a one-time import of 200 new Leads from a trade show uses the Import Wizard. A data team migrating 80,000 historical Cases from a legacy system uses Data Loader.

🎤 “Data Import Wizard is for small, guided imports on limited objects; Data Loader handles large-scale, any-object operations including delete and export.”

Q037🟠

What file formats does Data Loader support?

Data Loader primarily uses CSV files for import and export operations.

🔑 Key Points

It connects via CSV for data in/out, and can also connect directly to a database via JDBC for advanced use cases. Field mapping between CSV columns and Salesforce fields is done through a mapping file or interactively during the load.

🌍 XYZ Company / Example

A data team exports 50,000 Contact records to CSV, cleans the data in Excel, then re-imports via Data Loader using upsert with an External ID to update the correct records.

🎤 “Data Loader works with CSV files as its primary format, with optional JDBC database connections for advanced scenarios.”

Q038🟠

What is an Upsert operation?

Upsert combines Insert and Update in one operation — if a matching record is found (using an External ID or Record ID), it updates it; if not found, it inserts a new record.

🔑 Key Points

Upsert requires a unique identifier field marked as External ID (or the standard Id) to determine whether a match exists. This is the safest way to load data repeatedly without creating duplicates.

🌍 XYZ Company / Example

A nightly integration job upserts Order records from an ERP system using an ERP_Order_Number__c External ID field — existing orders get updated, new ones get created, with zero duplicate risk.

🎤 “Upsert inserts new records or updates existing ones based on a matching External ID, preventing duplicates during repeated data loads.”

Q039🟠

What is the External ID field used for?

The External ID field marks a custom field as a unique identifier for records — typically matching an ID from an outside system — enabling Upsert operations and easier system-to-system data matching.

🔑 Key Points

External ID fields are indexed automatically for faster lookups. They can be marked required and unique to enforce data integrity. Common use case: an ERP or legacy system's record ID stored on the Salesforce record for two-way sync reference.

🌍 XYZ Company / Example

An integration syncing Products from SAP stores the SAP Material Number as an External ID field on Product2 — every sync uses that field to match records instead of relying on Salesforce's internal Record ID.

🎤 “External ID fields uniquely identify records against an outside system's ID, enabling reliable Upsert-based integrations.”

Q040🟠

What is a Duplicate Rule vs Matching Rule?

A Matching Rule defines the criteria for identifying potential duplicate records (which fields to compare and how). A Duplicate Rule uses a Matching Rule and defines what action to take when a duplicate is found — block, allow with alert, or report only.

🔑 Key Points

Standard Matching Rules exist for Account, Contact, and Lead. Custom Matching Rules can be built for other objects. Duplicate Rules can be set to run on create/edit and can allow admins to override the block.

🌍 XYZ Company / Example

A company sets a Matching Rule comparing Email + Company Name on Leads, then a Duplicate Rule that blocks creation if a match is found — preventing sales reps from creating duplicate Lead records for the same prospect.

🎤 “Matching Rules define how duplicates are identified; Duplicate Rules define what action to take (block or alert) when a match is found.”

Q041🟠

What is Data Skew?

Data Skew occurs when a single record (like an Account) has an extremely high number of related child records or is owned by a single user, causing performance issues and lock contention during bulk operations.

🔑 Key Points

Account Data Skew: one Account with 100,000+ child records causes slow queries and lock timeouts. Ownership Skew: one user owning 10,000+ records of an object causes sharing recalculation slowdowns. Both are common in large enterprise orgs and require careful data architecture planning.

🌍 XYZ Company / Example

A telecom company had one 'unassigned' user owning 200,000 Leads, causing sharing rule recalculations to take hours. Fixing ownership skew by distributing ownership across more users or using Queues resolved the performance issue.

🎤 “Data Skew happens when too many child records relate to one parent, or too many records are owned by one user — both degrade performance and require careful data distribution.”

Q042🟠

What is the difference between Hard Delete and Soft Delete (Recycle Bin)?

A normal delete (Soft Delete) moves a record to the Recycle Bin, where it can be restored for a limited time. A Hard Delete permanently removes the record immediately, bypassing the Recycle Bin entirely.

🔑 Key Points

Hard Delete requires special permission ('Bulk API Hard Delete' or specific Data Loader settings) since it's irreversible. Regular users deleting records via UI always get Soft Delete first.

🌍 XYZ Company / Example

A data migration team hard-deletes test records created during a sandbox refresh to avoid clutter, since those records have no business value and don't need Recycle Bin recovery.

🎤 “Soft Delete moves records to the Recycle Bin (recoverable); Hard Delete permanently removes them immediately and requires special permission.”

Q043🟢

How long do records stay in the Recycle Bin?

Records stay in the Recycle Bin for 15 days before being permanently purged.

🔑 Key Points

Admins and users can manually empty the Recycle Bin before 15 days if needed. Storage limits also apply — if the Recycle Bin exceeds a certain size, the oldest records may be purged early to make room.

🌍 XYZ Company / Example

A user accidentally deletes 50 Opportunity records — as long as it's within 15 days, they (or an admin) can go to the Recycle Bin and restore them with all field data intact.

🎤 “Deleted records remain recoverable in the Recycle Bin for 15 days before permanent purge.”

Q044🟠

What is Mass Transfer of records?

Mass Transfer Records is an admin tool that changes the owner of multiple records at once, based on filter criteria — commonly used when an employee leaves or a territory is reorganized.

🔑 Key Points

Available under Setup → Mass Transfer Records for standard objects like Accounts, Leads, and Cases (and configurable for custom objects). It can optionally transfer related open Activities and Cases along with the primary record.

🌍 XYZ Company / Example

When a Sales Rep leaves the company, an admin uses Mass Transfer to reassign all their open Opportunities and Leads to their replacement in one action instead of updating hundreds of records manually.

🎤 “Mass Transfer Records reassigns ownership of many records at once based on filter criteria, commonly used for employee transitions.”

Q045🟢

What are Reports and Dashboards?

Reports display Salesforce data in rows/columns/summaries based on chosen filters and groupings. Dashboards are visual representations (charts, graphs) built on top of one or more Reports.

🔑 Key Points

Reports are the data source; Dashboards are the visualization layer. A single Dashboard can pull from multiple different Reports. Both can be scheduled to refresh and emailed automatically.

🌍 XYZ Company / Example

A Sales Manager builds a Report showing Opportunities by Stage, then adds a Dashboard chart visualizing that Report as a funnel — giving an at-a-glance view instead of reading raw rows.

🎤 “Reports show underlying data in tabular/summary form; Dashboards visualize that report data as charts and graphs for quick insights.”

Q046🟠

What is the difference between a Report and a List View?

A List View shows a simple filtered list of records from ONE object with basic columns. A Report can pull from multiple related objects, apply groupings, summaries, formulas, and charts.

🔑 Key Points

List Views are quicker to set up but far less powerful — no cross-object joins, no summary formulas, no charting (beyond a simple chart in newer releases). Reports support Report Types that join related objects (e.g., Accounts with Opportunities).

🌍 XYZ Company / Example

A quick List View shows 'My Open Cases' for an agent's daily work queue. A Report shows 'Cases Closed by Month by Product Category' with grouped summaries for a quarterly business review.

🎤 “List Views are simple single-object filtered lists; Reports offer advanced grouping, cross-object data, and summary calculations.”

Q047🟠

What are the 4 types of Reports?

Tabular (simple row-by-row list, no grouping), Summary (grouped rows with subtotals), Matrix (grouped by both rows AND columns, like a pivot table), and Joined (combines multiple report types/blocks in one report).

🔑 Key Points

Tabular reports cannot be used directly on Dashboards if they have no row limit set (need a row limit for charting). Matrix reports are the most powerful for cross-tabulated analysis. Joined reports let you compare completely different objects (e.g., Opportunities and Cases) side by side.

🌍 XYZ Company / Example

A simple export of 'All Contacts' uses Tabular. 'Opportunities Grouped by Stage' uses Summary. 'Opportunities by Stage AND by Sales Rep' (rows and columns) uses Matrix.

🎤 “The four report types are Tabular (simple list), Summary (grouped rows), Matrix (grouped rows and columns), and Joined (multiple report blocks combined).”

Q048🟠

Can a Dashboard be scheduled? How?

Yes. Dashboards can be scheduled to refresh automatically at set intervals (daily, weekly, monthly) and can also be configured to email a snapshot to specified recipients.

🔑 Key Points

Scheduling is set via the Dashboard's 'Refresh' dropdown → Schedule Refresh. The Dashboard always runs as a specific 'Running User' — meaning all viewers see data based on THAT user's access, not their own (unless 'View dashboard as logged-in user' is enabled).

🌍 XYZ Company / Example

An Executive Dashboard is scheduled to refresh every morning at 6am and email a PDF snapshot to the leadership team before their 9am meeting, without anyone needing to manually open Salesforce.

🎤 “Dashboards can be scheduled to auto-refresh and email snapshots to recipients at set intervals.”

Q049🟢

What is a Report Type?

A Report Type defines which objects and fields are available when building a Report — essentially the template determining what data can be pulled together.

🔑 Key Points

Standard Report Types come pre-built for common object relationships (e.g., 'Opportunities with Products'). Custom Report Types let admins define specific joins between objects that aren't available by default, including up to 4 objects in a chain.

🌍 XYZ Company / Example

An admin needs a report showing Cases along with their related Knowledge Articles — since no standard Report Type supports this combination, they create a Custom Report Type joining Case and Knowledge Article.

🎤 “A Report Type is the template defining which objects and fields are available for building a specific Report.”

Q050🟢

What is a Joined Report?

A Joined Report combines multiple report blocks (potentially from different report types/objects) into a single report, letting you compare unrelated data side by side.

🔑 Key Points

Each block in a Joined Report can have its own columns, filters, and groupings, but they share a common set of groupings across the top. Useful for executive-level reports comparing metrics across different objects.

🌍 XYZ Company / Example

A Joined Report combines an 'Opportunities Closed This Quarter' block with a 'Cases Opened This Quarter' block, letting leadership see sales and support trends together in one view grouped by month.

🎤 “A Joined Report lets you combine multiple report blocks from different objects into a single unified view for cross-object comparison.”

⚙️

Process Automation

Q51–Q70 · Flow, Process Builder, Workflow, and Approvals

Q051🟢

What is Flow Builder?

Flow Builder is Salesforce's primary declarative automation tool — used to build complex business logic through a visual, drag-and-drop interface, without writing code.

🔑 Key Points

Flow can query and update records, show custom screens to users, call Apex, send emails, and integrate with external systems (via HTTP callouts in newer versions). It's Salesforce's recommended tool going forward, replacing Workflow Rules and Process Builder.

🌍 XYZ Company / Example

A company builds a Screen Flow that guides a new employee through account setup step by step, collecting information across multiple screens and creating multiple related records at the end.

🎤 “Flow Builder is Salesforce's modern, no-code automation tool for building everything from simple field updates to complex multi-step business processes.”

Q052🟠

What are the types of Flows?

Screen Flow (interactive, user fills out screens), Record-Triggered Flow (fires automatically on record create/update/delete), Scheduled Flow (runs at a specific time/interval, no trigger needed), and Autolaunched Flow (runs via Apex, another Flow, or a button — no screens).

🔑 Key Points

Record-Triggered Flows are the modern replacement for Workflow Rules and Process Builder. Scheduled Flows are useful for batch-style processes like daily cleanup or aging alerts. Screen Flows are used in Experience Cloud portals and agent-guided processes in the Service Console.

🌍 XYZ Company / Example

A 'Password Reset Wizard' uses a Screen Flow. Auto-updating a Case's Priority when created uses a Record-Triggered Flow. A nightly job auto-closing stale Cases uses a Scheduled Flow.

🎤 “Flow types are Screen (interactive UI), Record-Triggered (automatic on DML), Scheduled (time-based), and Autolaunched (invoked by other automation).”

Q053🟠

What is the difference between a Before-Save Flow and an After-Save Flow?

A Before-Save (Record-Triggered) Flow updates fields on the SAME record before it's committed to the database — extremely fast, no extra DML needed. An After-Save Flow runs after the record is committed and can update OTHER records, send emails, or call Apex.

🔑 Key Points

Before-Save Flows are significantly more performant since they avoid a second database round-trip (no re-save needed) — Salesforce recommends using Before-Save whenever you're only updating fields on the triggering record itself.

🌍 XYZ Company / Example

Auto-calculating a 'Total Price' field on the same Opportunity record uses a Before-Save Flow (fast, same record). Sending a follow-up email or creating a related Task uses an After-Save Flow.

🎤 “Before-Save Flows update the same record efficiently pre-commit; After-Save Flows handle related-record updates, emails, and other actions post-commit.”

Q054🟠

What is Process Builder? Is it still used?

Process Builder was a visual automation tool (predecessor to modern Flow) using a linear 'if this, then that' structure. Salesforce has officially retired it — Flow Builder is now the recommended tool for all new automation.

🔑 Key Points

Existing orgs may still have legacy Process Builder processes running, and Salesforce provides a Migrate to Flow tool to convert them. New development should never start in Process Builder — it's a common interview trap question to test if candidates know current best practice.

🌍 XYZ Company / Example

A legacy org built a Process Builder in 2019 to send an email on Opportunity close. Today, an admin would rebuild that exact same logic using a Record-Triggered Flow instead.

🎤 “Process Builder is retired — Flow Builder is now the standard tool, and existing Process Builders should be migrated using Salesforce's Migrate to Flow tool.”

Q055🟠

What is Workflow Rule? Name its actions.

Workflow Rule is a legacy (now retired) automation tool that fires simple actions when a record meets criteria. Its actions were: Field Update, Email Alert, Task creation, and Outbound Message.

🔑 Key Points

Like Process Builder, Workflow Rules are retired in favor of Flow. Outbound Message (sending record data to an external endpoint via SOAP) was Workflow Rule's most unique action, which Flow now also supports via HTTP Callout actions.

🌍 XYZ Company / Example

A legacy Workflow Rule auto-creates a follow-up Task when a Case is marked High Priority — today this would be built as a Record-Triggered Flow with a Create Records element.

🎤 “Workflow Rules (now retired) supported four actions — Field Update, Email Alert, Task, and Outbound Message — all now handled by Flow Builder.”

Q056🟢

Why is Salesforce retiring Workflow Rules and Process Builder in favor of Flow?

Flow consolidates automation into a single, more powerful, more performant tool — eliminating the confusion and conflict risk of having three separate automation tools (Workflow, Process Builder, Flow) potentially firing on the same record.

🔑 Key Points

Having multiple automation tools on one object made execution order unpredictable and debugging harder. Flow supports everything the older tools did plus loops, subflows, screen-based UI, and better error handling — making it a strict superset of capability.

🌍 XYZ Company / Example

An org that previously had a Workflow Rule, a Process Builder, AND a Trigger all firing on Case update consolidates everything into a single well-ordered Record-Triggered Flow, making the automation easier to debug and maintain.

🎤 “Flow replaces Workflow Rules and Process Builder because it's more powerful, more performant, and eliminates the complexity of managing multiple separate automation tools on the same object.”

Q057🟠

What is an Approval Process?

An Approval Process is a formal, multi-step workflow requiring one or more designated users to approve or reject a record before it proceeds — commonly used for discount approvals, expense reports, or PTO requests.

🔑 Key Points

Components: Entry Criteria (when it triggers), Approval Steps (who approves, in what order), Actions (what happens on approval/rejection/recall — like field updates or email alerts). Can route to a specific user, the record owner's manager, or a queue.

🌍 XYZ Company / Example

A Sales Rep submits an Opportunity with a 40% discount — this exceeds their approval limit, so it routes through an Approval Process to their Sales Manager, and if approved, a Field Update marks the discount as Approved.

🎤 “An Approval Process is a formal, multi-step record approval workflow with defined approvers, actions, and criteria — commonly used for discounts, expenses, and time-off requests.”

Q058🟠

Can a Flow call an Apex class?

Yes. A Flow can call Apex through an Invocable Method — an Apex method annotated with @InvocableMethod that Flow can recognize and call as an action.

🔑 Key Points

This is the standard pattern for handling complex logic that's easier in code than clicks — like calling an external API, doing heavy calculations, or bulk-processing records efficiently. The Apex method must accept a List of inputs (bulk-safe) and return a List of outputs.

🌍 XYZ Company / Example

A Flow needs to calculate complex shipping costs based on weight, distance, and carrier rules — too complex for Flow's formula editor, so it calls an Invocable Apex method that returns the calculated cost.

🎤 “Flows call Apex through Invocable Methods — Apex classes with an @InvocableMethod-annotated method that Flow can trigger as an action.”

Q059🟠

What is a Fault Path in Flow?

A Fault Path is an alternate path a Flow takes when an element (like a DML operation or Apex call) fails — allowing the Flow to handle errors gracefully instead of crashing with an unhandled exception.

🔑 Key Points

Every element that could fail (Create Records, Update Records, Apex Action) has a Fault Path connector option. Best practice: always add fault paths on DML/Apex elements to log the error or notify an admin instead of leaving users with a cryptic system error.

🌍 XYZ Company / Example

A Flow creating a new Case might fail if a required field is missing — the Fault Path catches this, logs the error to a custom object, and shows the user a friendly message instead of a raw Salesforce error screen.

🎤 “A Fault Path handles errors gracefully when a Flow element fails, letting the Flow log the issue or notify someone instead of crashing with a raw error.”

Q060🟠

What is the Get Records element used for in Flow?

Get Records queries Salesforce data within a Flow — similar to a SOQL query — retrieving one or more records matching specified filter criteria for use later in the Flow.

🔑 Key Points

Can return a single record or a collection of records. Best practice: only retrieve the specific fields needed (though Flow retrieves reasonable defaults) and always filter to avoid returning excessive records, which can hit governor limits in bulk scenarios.

🌍 XYZ Company / Example

A Flow needs to check if a Contact already has an open Case before creating a new one — it uses Get Records filtered by ContactId and Status='Open' to check first.

🎤 “Get Records queries Salesforce data within a Flow, similar to a SOQL query, retrieving records that match specified filter criteria.”

Q061🟠

What is a Formula Resource in Flow?

A Formula Resource is a reusable calculated value within a Flow — built using formula syntax (similar to Formula fields) — that can reference Flow variables and be used across multiple elements.

🔑 Key Points

Unlike a Formula field (which lives on the object permanently), a Formula Resource only exists within that specific Flow's execution. Useful for calculations that need to happen mid-Flow, like combining variables or doing date math before a decision element.

🌍 XYZ Company / Example

A Flow collects First Name and Last Name on separate screen fields, then uses a Formula Resource to concatenate them into a single 'Full Name' value used later in an email template.

🎤 “A Formula Resource is a Flow-scoped calculated value using formula syntax, useful for combining or transforming data mid-Flow.”

Q062🟠

What is the difference between Screen Flow and Autolaunched Flow?

A Screen Flow displays interactive screens for a user to fill out and navigate. An Autolaunched Flow runs entirely in the background with no user interface — triggered by automation, a button, or another process.

🔑 Key Points

Screen Flows are used in guided processes (agent scripts, self-service wizards, community forms). Autolaunched Flows handle pure backend logic — like the underlying logic called by a Quick Action button, or logic invoked from Apex/Process/another Flow.

🌍 XYZ Company / Example

A customer self-service 'Submit a Case' form on a portal is a Screen Flow. Behind the scenes, a Quick Action button 'Escalate Case' that updates fields with no user input needed uses an Autolaunched Flow.

🎤 “Screen Flows show interactive UI screens to users; Autolaunched Flows run silently in the background with no screens.”

Q063🟢

Can Flow be triggered by another Flow?

Yes, using a Subflow element — one Flow can call another Flow as a component within it, passing variables in and out.

🔑 Key Points

This enables modular Flow design — building reusable Flow 'building blocks' (like a common error-logging subflow) that multiple parent Flows can call, avoiding duplicated logic across the org.

🌍 XYZ Company / Example

A company builds a reusable 'Send Standard Notification' Subflow, then calls it from 10 different parent Flows across different objects whenever they need to notify a manager — avoiding rebuilding that logic 10 times.

🎤 “Yes — Flows can call other Flows using the Subflow element, enabling reusable, modular automation building blocks.”

Q064🟠

What is a Scheduled-Triggered Flow used for?

A Scheduled-Triggered Flow (Scheduled Flow) runs automatically at a specified date/time and frequency, without needing a record to be created or edited — commonly used for batch-style cleanup or reminder processes.

🔑 Key Points

Configured with a start date, frequency (once, daily, weekly), and time of day. Often built as 'Schedule-Triggered Flow with entry conditions' to process a batch of records matching criteria (like 'all Cases open more than 5 days').

🌍 XYZ Company / Example

A Scheduled Flow runs every night at 1am, finds all Opportunities with a Close Date in the past that are still Open, and sends a reminder email to the owner to update the stage.

🎤 “Scheduled Flows run automatically at set times/intervals to process batches of records, commonly for reminders, cleanup, or aging alerts.”

Q065🟠

What is a Loop element in Flow used for?

The Loop element iterates through a collection of records (or values) one at a time, allowing the Flow to perform an action on each item in that collection.

🔑 Key Points

Common pattern: Get Records (returns a collection) → Loop through the collection → inside the loop, do calculations or assignments → after the loop, bulk-update all records at once using a collection variable (never DML inside the loop itself for bulk safety).

🌍 XYZ Company / Example

A Flow retrieves all open Cases for an Account, loops through each one to check its age, and adds any Case older than 5 days to a collection — which is then bulk-updated with an Escalated flag after the loop finishes.

🎤 “The Loop element iterates through a collection of records one at a time so the Flow can process or evaluate each item individually.”

Q066🟢

What is a Decision element in Flow?

A Decision element branches the Flow's path based on conditions — similar to an if/else statement — routing execution down different paths depending on which condition is met.

🔑 Key Points

A Decision can have multiple outcome paths plus a Default Outcome (fallback if no condition matches). Conditions can check any Flow variable, formula, or record field value retrieved earlier in the Flow.

🌍 XYZ Company / Example

A Decision element checks if Case Priority = 'Critical' → routes to an escalation path; if Priority = 'Low' → routes to a standard path; Default Outcome handles any other value.

🎤 “A Decision element branches Flow execution into different paths based on conditions, similar to an if/else statement.”

Q067🟢

What is an Assignment element in Flow?

An Assignment element sets or changes the value of a Flow variable — assigning a value, adding to a collection, or performing simple math operations like incrementing a counter.

🔑 Key Points

Common operations: Equals (set a value), Add (append to collection or increment number), Subtract, Remove (from collection). Used constantly inside loops to build up collections for later bulk DML operations.

🌍 XYZ Company / Example

Inside a Loop, an Assignment element adds each qualifying Case record to a collection variable called 'casesToUpdate', which is then used in a single bulk Update Records element after the loop completes.

🎤 “An Assignment element sets, changes, or adds to a Flow variable's value — commonly used to build up collections during a loop.”

Q068🟠

Can a Flow update a record without triggering another automation (recursion)?

Yes — Flow update elements have an option to control whether other automation re-fires on that same update, and best practice is to design Flows to avoid unnecessary recursion using entry condition checks or a 'don't run again' flag pattern.

🔑 Key Points

In Record-Triggered Flows, if a Flow updates the same record type it's triggered on, it can cause infinite loops unless carefully controlled. Common pattern: adding entry criteria that only fire the Flow when a SPECIFIC field actually changed (not just any save), preventing needless re-triggering.

🌍 XYZ Company / Example

A Flow that sets 'Priority=High' when a Case is escalated is configured with entry criteria checking 'Escalated changed to true' — so updating the Case again after that doesn't re-trigger the same Flow logic infinitely.

🎤 “Yes — Flow recursion is controlled through careful entry criteria design (only firing on specific field changes) to prevent infinite update loops.”

Q069🟠

What is a Subflow?

A Subflow is a Flow element that calls another, separate Flow as a reusable component — passing input/output variables between the parent and child Flow.

🔑 Key Points

Enables modular, DRY (Don't Repeat Yourself) automation design. The called Flow must be Active and marked as available for use as a Subflow. Changes to the Subflow logic automatically apply everywhere it's used, without needing to update every parent Flow individually.

🌍 XYZ Company / Example

A 'Log Error' Subflow creates a record in a custom Error_Log__c object — this Subflow is called from 15 different parent Flows across the org whenever something needs standardized error logging.

🎤 “A Subflow lets one Flow call another as a reusable component, promoting modular design and centralized logic reuse.”

Q070🟠

What are Flow best practices for avoiding recursion?

Use entry conditions that check for specific field changes (not just 'any update'), use Before-Save Flows for same-record field updates instead of After-Save, and avoid unconditional Update Records elements on the triggering object.

🔑 Key Points

Additional best practices: bulkify by using collections and single DML statements instead of DML inside loops, add Fault Paths to all DML/Apex elements, and document Flow purpose clearly since multiple Flows on one object can become hard to trace without good naming/description.

🌍 XYZ Company / Example

A team building Flows on Opportunity ensures each Flow only fires on specific, non-overlapping field changes (one Flow watches Stage changes, another watches Amount changes) to avoid two Flows fighting each other or causing unexpected recursive updates.

🎤 “Flow recursion is avoided through precise entry criteria, Before-Save Flows for same-record updates, bulkified logic, and clear separation of concerns across multiple Flows.”

💻

Apex Basics

Q71–Q95 · Triggers, collections, SOQL, and testing

Q071🟢

What is Apex? Is it case-sensitive?

Apex is Salesforce's proprietary, strongly-typed, object-oriented programming language — syntactically similar to Java — used to write custom business logic that runs on the Salesforce platform.

🔑 Key Points

Apex is NOT case-sensitive for identifiers (variable/method/class names), unlike Java. It runs entirely on Salesforce's servers (not client-side) and is tightly integrated with the database through built-in SOQL and DML support.

🌍 XYZ Company / Example

A developer writes an Apex class to calculate complex commission structures that involve multiple related objects and business rules too complex for declarative tools like Flow.

🎤 “Apex is Salesforce's Java-like, case-insensitive, strongly-typed programming language for writing custom server-side business logic.”

Q072🟢

What is the difference between a Trigger and an Apex Class?

A Trigger is Apex code that automatically executes in response to a DML event (insert, update, delete, undelete) on a specific object. An Apex Class is a general container for reusable code, methods, and logic that must be explicitly called.

🔑 Key Points

Best practice: keep Triggers extremely thin (just calling a Trigger Handler class) and put all actual logic in a separate Apex Class — this makes code more testable, reusable, and avoids the 'one trigger per object' rule being violated by accident. Want to go deeper on trigger patterns and best practices? Check our dedicated Apex Triggers question bank.

🌍 XYZ Company / Example

A CaseTrigger fires on Case insert/update, but instead of writing logic directly in the trigger, it calls a single line: CaseTriggerHandler.handleBeforeUpdate(Trigger.new) — keeping the actual logic organized in the handler class.

🎤 “A Trigger automatically fires on DML events for a specific object; an Apex Class is reusable code that must be explicitly invoked — best practice keeps Triggers thin and delegates logic to handler classes.”

Q073🟠

What are Trigger Events?

Trigger Events define when a Trigger's code executes relative to the DML operation: before insert, after insert, before update, after update, before delete, after delete, and after undelete.

🔑 Key Points

Before events: used for validating or modifying field values on the SAME record before it saves (efficient, no extra DML). After events: used when you need the Record ID (auto-number, etc.) or need to update RELATED records.

🌍 XYZ Company / Example

A trigger uses 'before insert' to auto-populate a default value on a new Case. It uses 'after insert' to create a related Task record, since it needs the new Case's ID first (which only exists after insert).

🎤 “Trigger Events (before/after insert/update/delete, after undelete) define exactly when trigger logic runs relative to the database operation.”

Q074🟠

What is the difference between Trigger.new and Trigger.old?

Trigger.new contains the NEW version of the records being processed (available in insert/update/undelete contexts). Trigger.old contains the OLD version before changes (available in update/delete contexts).

🔑 Key Points

In an update trigger, Trigger.new has the incoming changed values while Trigger.old has the previous saved values — comparing them lets you detect exactly which field changed. Trigger.new is editable in before-context triggers; Trigger.old is always read-only.

🌍 XYZ Company / Example

A trigger compares Trigger.new[0].Status with Trigger.old[0].Status to detect if a Case's status specifically changed to 'Closed', and only then sends a closure email — avoiding sending it on every unrelated field update.

🎤 “Trigger.new holds the incoming/updated record values, while Trigger.old holds the previous values — comparing them detects exactly what changed.”

Q075🟠

Why should you avoid SOQL/DML inside a for loop?

Salesforce enforces Governor Limits — a maximum of 100 SOQL queries and 150 DML statements per transaction. Putting a query or DML statement inside a loop means it runs once PER RECORD, quickly hitting these limits when processing bulk data.

🔑 Key Points

This is the single most common Apex interview trap question. The fix: query all needed data BEFORE the loop (store in a Map or List), do calculations inside the loop using in-memory collections, then perform a single bulk DML statement AFTER the loop finishes.

🌍 XYZ Company / Example

Instead of querying the related Account inside a loop over 200 Contacts (200 SOQL queries — limit exceeded), a developer queries all needed Accounts once into a Map before the loop, then looks up from that map inside the loop.

🎤 “SOQL/DML inside a loop multiplies operations per record and quickly breaches Salesforce's Governor Limits — always query/DML in bulk outside the loop.”

Q076🟢

What are Governor Limits? Name a few.

Governor Limits are hard resource limits Salesforce enforces per transaction to ensure the shared, multi-tenant platform runs fairly for all customers — exceeding them throws an uncatchable runtime exception.

🔑 Key Points

Common limits: 100 SOQL queries per transaction, 150 DML statements, 50,000 records retrieved by SOQL, 10,000 records processed by DML, and a 6-second (synchronous) or longer (asynchronous) CPU time limit. These exist specifically to force developers to write bulkified, efficient code.

🌍 XYZ Company / Example

A poorly written trigger that queries inside a loop works fine with 5 test records but throws 'Too many SOQL queries: 101' when a real Data Loader import of 200 records fires it at once — a classic governor limit failure caught only at scale.

🎤 “Governor Limits are Salesforce's hard resource caps (SOQL queries, DML statements, record limits, CPU time) per transaction, enforced to keep the multi-tenant platform fair and performant.”

Q077🟠

What is Bulkification in Apex?

Bulkification means writing Apex code that efficiently processes MULTIPLE records at once (in collections), rather than assuming only a single record will ever be processed — essential because triggers can fire on batches of up to 200 records at once.

🔑 Key Points

Non-bulkified code often works fine in manual UI testing (1 record at a time) but breaks catastrophically during bulk operations like Data Loader imports or API calls — which is exactly why governor limits exist to force this discipline.

🌍 XYZ Company / Example

A bulkified trigger handler processes Trigger.new as a whole List, builds a single Map of related Account IDs, queries all needed Accounts in ONE query, then loops through in memory — handling 1 record or 200 records with the same, predictable performance.

🎤 “Bulkification means designing Apex code to efficiently handle collections of records at once, not just a single record — critical since triggers can process up to 200 records per invocation.”

Q078🟠

What is the difference between a Class and an Interface in Apex?

A Class contains actual implementation — real code, field values, and method bodies. An Interface only defines method SIGNATURES (name, parameters, return type) with no implementation — any class that implements the interface must provide the actual code.

🔑 Key Points

Interfaces enable polymorphism and loosely-coupled design — different classes can implement the same interface differently, and calling code can work with any of them through the shared interface type. Apex supports single inheritance for classes but multiple interface implementation.

🌍 XYZ Company / Example

An interface 'PaymentProcessor' defines a method processPayment(Decimal amount) with no body. A 'StripeProcessor' class and a 'PayPalProcessor' class each implement that interface differently — calling code just calls processPayment() without caring which one is used.

🎤 “A Class provides actual implementation; an Interface only defines method signatures that implementing classes must fulfill — enabling flexible, polymorphic design.”

Q079🟠

What is a Static variable in Apex?

A Static variable belongs to the CLASS itself rather than to any specific instance of the class — its value is shared across all instances and persists for the entire duration of a single transaction (not across transactions).

🔑 Key Points

Static variables are commonly used to prevent trigger recursion — setting a static Boolean flag to true the first time a trigger runs, then checking that flag to skip re-execution if the trigger somehow fires again within the same transaction.

🌍 XYZ Company / Example

A trigger handler uses 'public static Boolean alreadyRun = false;' — at the start of the handler it checks if alreadyRun is true (skip if so), otherwise sets it to true before proceeding, preventing infinite recursive trigger execution within one transaction.

🎤 “A Static variable is shared across all instances of a class for the duration of one transaction — commonly used to prevent recursive trigger execution.”

Q080🟢

What are the collection types in Apex?

Apex has three main collection types: List (ordered collection, allows duplicates, indexed), Set (unordered collection, no duplicates allowed), and Map (key-value pairs, unique keys).

🔑 Key Points

List: best when order matters or duplicates are okay (e.g., a list of Case records). Set: best for storing unique values like a set of Ids to avoid duplicates. Map: best for fast lookups by a key, like Map<Id, Account> for quick Account lookups by their Id without repeated queries.

🌍 XYZ Company / Example

A trigger builds a Set<Id> of unique Account Ids from a list of Contacts, then queries those Accounts once into a Map<Id, Account>, allowing instant lookup of any Account by Id inside a loop without additional SOQL.

🎤 “Apex's three collection types are List (ordered, allows duplicates), Set (unique values, unordered), and Map (key-value pairs for fast lookups).”

Q081🟢

What is the difference between List and Set?

A List maintains insertion order and allows duplicate values, accessed by index. A Set does NOT maintain order and automatically prevents duplicate values.

🔑 Key Points

Use a List when you need to preserve the sequence records were retrieved in, or when duplicates are meaningful. Use a Set when you only care about unique membership — like checking 'does this value already exist' efficiently.

🌍 XYZ Company / Example

A developer collects all Contact Emails into a Set<String> to automatically dedupe them before sending a mass email, avoiding sending the same person two emails if they appear twice in the source List.

🎤 “List preserves order and allows duplicates; Set enforces uniqueness with no guaranteed order — choose based on whether duplicates and order matter for your use case.”

Q082🟠

What is a Map used for in Apex?

A Map stores key-value pairs where each key is unique, enabling fast O(1) lookups of a value using its key — commonly used to avoid repeated SOQL queries inside loops.

🔑 Key Points

Extremely common pattern: query related records once BEFORE a loop into a Map keyed by Id, then inside the loop, use map.get(someId) to instantly retrieve the related record instead of querying again — this is central to writing bulkified, governor-limit-safe Apex.

🌍 XYZ Company / Example

Instead of querying the Account for each of 200 Contacts individually (200 queries), a developer builds Map<Id, Account> accountMap from one bulk query, then does accountMap.get(contact.AccountId) inside the loop — just 1 query total.

🎤 “A Map provides fast key-based lookups, most commonly used to cache related records queried once before a loop instead of querying repeatedly inside it.”

Q083🟠

What is SOQL? What is SOSL? What's the difference?

SOQL (Salesforce Object Query Language) queries records from ONE specific object (and its related objects) with precise filtering — similar to SQL SELECT. SOSL (Salesforce Object Search Language) performs a text search ACROSS MULTIPLE objects simultaneously.

🔑 Key Points

SOQL: use when you know exactly which object and fields you need (e.g., 'all Contacts where LastName = Smith'). SOSL: use for a global keyword search across several objects at once, like a search bar feature (e.g., 'find anything matching acme across Account, Contact, and Opportunity').

🌍 XYZ Company / Example

A report needing 'all Opportunities Closed Won this quarter' uses SOQL with precise filters. A global search box letting users type 'Acme' and see matching Accounts, Contacts, AND Opportunities all at once uses SOSL.

🎤 “SOQL queries structured data from a specific object with precise filters; SOSL performs text search across multiple objects simultaneously.”

Q084🔴

Can you write DML inside a loop? Why or why not?

Technically yes, but it's a serious anti-pattern that should always be avoided — DML inside a loop consumes one DML statement per iteration, quickly exceeding the 150 DML statements per transaction Governor Limit when processing more than a handful of records.

🔑 Key Points

Correct pattern: collect records to insert/update into a List OUTSIDE the loop during iteration, then perform ONE bulk DML statement (insert/update the whole List) AFTER the loop completes. This is one of the most frequently tested Apex concepts in interviews.

🌍 XYZ Company / Example

Instead of calling 'update contact;' inside a loop over 300 Contacts (300 DML statements, exceeds the 150 limit), a developer adds each modified Contact to a List<Contact>, then calls 'update contactsToUpdate;' ONE time after the loop.

🎤 “DML inside a loop should always be avoided — collect changes in a List during the loop, then perform a single bulk DML statement after the loop to stay within governor limits.”

Q085🟠

What is a Trigger Handler pattern and why is it used?

The Trigger Handler pattern moves all actual business logic OUT of the trigger itself and into a separate Apex class — the trigger becomes a thin one-liner that just delegates to the handler class's methods per context (before insert, after update, etc.).

🔑 Key Points

Benefits: keeps exactly ONE trigger per object (Salesforce best practice — multiple triggers on one object create unpredictable execution order), makes logic unit-testable independent of DML, and keeps code organized and maintainable as complexity grows.

🌍 XYZ Company / Example

AccountTrigger.trigger contains only: 'AccountTriggerHandler.run();' — all the actual before/after insert/update logic lives inside the AccountTriggerHandler class, checked into source control and tested independently.

🎤 “The Trigger Handler pattern keeps triggers thin (just delegation) while all real logic lives in a separate, testable Apex class — following the one-trigger-per-object best practice. For 25+ scenario-based trigger questions, see our Apex Triggers MCQ practice set.”

Q086🟠

What is Trigger.isBefore and Trigger.isInsert used for?

These are context variables Apex automatically provides inside a trigger to detect exactly WHICH event fired it — Trigger.isBefore/isAfter (timing) and Trigger.isInsert/isUpdate/isDelete/isUndelete (operation type).

🔑 Key Points

Since Salesforce allows only one trigger per object, but that trigger can be written to run in ALL contexts, these boolean flags let a single trigger correctly branch its logic depending on exactly which event triggered it.

🌍 XYZ Company / Example

A single AccountTrigger checks 'if(Trigger.isBefore && Trigger.isInsert)' to run default-value logic only during before-insert, and a completely separate 'if(Trigger.isAfter && Trigger.isUpdate)' block to run different logic only during after-update.

🎤 “Trigger context variables like Trigger.isBefore and Trigger.isInsert let a single trigger correctly branch logic depending on exactly which DML event and timing fired it.”

Q087🟢

What is an Apex Test Class? What is minimum required code coverage?

An Apex Test Class contains methods (marked @isTest) that verify other Apex code behaves correctly. Salesforce requires a minimum of 75% code coverage org-wide before deploying Apex to Production.

🔑 Key Points

Coverage alone isn't enough — tests must include meaningful assertions (System.assertEquals) that actually verify correct behavior, not just execute lines. Test classes should also test bulk scenarios (200 records) and negative/edge cases, not just the happy path.

🌍 XYZ Company / Example

A trigger with 20 lines of logic needs a test class covering at least 15 of those lines (75%) to deploy — but a good developer aims for 90%+ coverage AND tests bulk insert of 200 records plus at least one failure scenario.

🎤 “Apex Test Classes verify code correctness using @isTest methods, and Salesforce requires a minimum 75% code coverage org-wide before any Apex can be deployed to Production.”

Q088🟢

What is @isTest annotation?

The @isTest annotation marks a class or method as test-only code — it doesn't count against the org's total Apex code storage limit and only runs when explicitly executed as a test (never as part of normal application logic).

🔑 Key Points

Can be applied at the class level (@isTest class...) or method level (@isTest static void methodName()) within a regular class. Test methods must be static and typically void, and are the only place where Test.startTest()/Test.stopTest() are used.

🌍 XYZ Company / Example

A class 'AccountTriggerHandlerTest' is annotated @isTest and contains multiple test methods, each verifying a different scenario of the AccountTriggerHandler's logic — this test class is never called by regular users, only by the testing framework.

🎤 “@isTest marks classes/methods as test-only code that doesn't count against Apex storage limits and only executes during test runs.”

Q089🟠

What is Test.startTest() and Test.stopTest() used for?

Test.startTest() and Test.stopTest() mark the boundary of the code being actively tested — resetting Governor Limits at startTest() (giving the tested code a fresh limit budget) and forcing any asynchronous operations (Future, Batch, Queueable) to execute synchronously before stopTest() completes.

🔑 Key Points

Anything BEFORE startTest() is considered setup (like creating test data) and doesn't count toward the fresh limits. This pattern is essential for testing async Apex, since without stopTest(), Future/Queueable/Batch jobs wouldn't actually execute within the test's lifetime.

🌍 XYZ Company / Example

A test creates 200 test Account records (setup, before startTest), then calls Test.startTest(), performs the actual insert that fires the trigger being tested, then Test.stopTest() — ensuring any @future callout inside that trigger actually runs before assertions are checked.

🎤 “Test.startTest()/stopTest() bracket the code under test — resetting governor limits and forcing asynchronous Apex (Future/Batch/Queueable) to run synchronously within the test.”

Q090🟠

What is System.assertEquals used for?

System.assertEquals(expectedValue, actualValue) verifies that a test produced the expected result — if the values don't match, the test fails with a clear error message, making it the core tool for validating that code behaves correctly.

🔑 Key Points

Related assertions: System.assert(booleanCondition) for simple true/false checks, and System.assertNotEquals() for verifying values are different. Modern Apex also supports Assert.areEqual() as a newer, more descriptive alternative. Tests without real assertions technically 'pass' but prove nothing.

🌍 XYZ Company / Example

After inserting a Case expected to auto-set Priority='High', a test asserts: System.assertEquals('High', insertedCase.Priority, 'Priority should default to High') — if the trigger logic is broken, this assertion fails and flags exactly what went wrong.

🎤 “System.assertEquals compares an expected value against the actual result, failing the test with a clear message if they don't match — the core mechanism for proving code correctness.”

Q091🟠

What is a Custom Exception in Apex?

A Custom Exception is a user-defined exception class (extending the built-in Exception class) that lets developers throw and catch specific, meaningful error types relevant to their business logic, rather than relying only on generic system exceptions.

🔑 Key Points

Created by writing: public class MyCustomException extends Exception {} — then thrown using 'throw new MyCustomException('message');' and caught with a matching catch block. Makes error handling more precise and code more self-documenting.

🌍 XYZ Company / Example

A payment processing class defines 'InsufficientFundsException extends Exception' and throws it specifically when a payment amount exceeds available balance — calling code can catch that exact exception type and show a targeted error message.

🎤 “A Custom Exception is a user-defined class extending Exception, enabling precise, business-specific error handling beyond generic system exceptions.”

Q092🟠

What is try-catch used for in Apex?

try-catch handles runtime errors gracefully — code that might fail is wrapped in a 'try' block, and if an exception occurs, control passes to the matching 'catch' block instead of crashing the entire transaction with an unhandled error.

🔑 Key Points

An optional 'finally' block always executes regardless of whether an exception occurred, often used for cleanup logic. Best practice: catch specific exception types (like DmlException) rather than broad, generic Exception catches whenever possible, so real bugs aren't silently swallowed.

🌍 XYZ Company / Example

A DML insert wrapped in try-catch: if the insert fails due to a validation rule, the catch block logs the error to a custom Error_Log__c record and shows the user a friendly message instead of the transaction crashing entirely.

🎤 “try-catch wraps risky code so exceptions are handled gracefully with meaningful error responses, instead of crashing the entire transaction.”

Q093🟠

What is the difference between synchronous and asynchronous Apex?

Synchronous Apex executes immediately, in real-time, as part of the current transaction — the user waits for it to finish. Asynchronous Apex is queued to run separately (in the background), freeing up the current transaction and getting its own separate, often higher, governor limits.

🔑 Key Points

Synchronous: standard triggers, standard controller methods — fast, immediate, but limited by tight governor limits (like 6-second CPU time). Asynchronous (Future, Queueable, Batch, Scheduled): used for long-running processes, bulk data processing, or callouts that shouldn't block the user.

🌍 XYZ Company / Example

A trigger that needs to call an external API can't do so synchronously (callouts aren't allowed in triggers directly) — so it uses a @future(callout=true) method to make that API call asynchronously in the background instead.

🎤 “Synchronous Apex runs immediately within the current transaction with standard limits; Asynchronous Apex runs separately in the background with different (often higher) limits, ideal for long-running or callout-heavy processes.”

Q094🟢

Name types of Asynchronous Apex.

Future Methods (simple background tasks, especially callouts), Batch Apex (processing large data volumes in chunks), Queueable Apex (modern alternative to Future, supports complex parameter types and job chaining), and Scheduled Apex (runs on a cron-like schedule).

🔑 Key Points

Future: simplest, but limited to primitive parameter types, no job chaining, no monitoring. Queueable: supports complex objects as parameters, can be chained (one job enqueues another), and can be monitored via Job Id. Batch: processes millions of records in manageable chunks via start/execute/finish methods. Scheduled: implements the Schedulable interface with a cron expression.

🌍 XYZ Company / Example

A nightly job to recalculate a rollup field across 2 million Account records uses Batch Apex (processes in chunks of up to 200 at a time). A single async callout to update one external system after a record saves uses a Future method or Queueable.

🎤 “The four asynchronous Apex types are Future Methods, Batch Apex, Queueable Apex, and Scheduled Apex — each suited to different scale and complexity needs.”

Q095🟠

What is a Future Method? When would you use it?

A Future Method is an Apex method annotated with @future that runs asynchronously in the background, commonly used for making callouts to external systems (which aren't allowed directly inside triggers) or offloading heavy processing outside the current transaction.

🔑 Key Points

Limitations: parameters must be primitive types (String, Integer, etc. — no sObjects or complex objects directly), can't be called from another Future method, and execution timing isn't guaranteed (queued, runs when resources are available). Queueable Apex is often preferred today since it overcomes several of these limitations.

🌍 XYZ Company / Example

A trigger on Case needs to notify an external logging system via HTTP callout when a Case is closed — since callouts aren't allowed synchronously in triggers, it calls a @future(callout=true) method to handle that notification in the background.

🎤 “A Future Method (@future annotation) runs Apex asynchronously in the background, most commonly used for external callouts that aren't permitted directly inside a trigger's synchronous execution.”

⚡

Lightning Web Components (LWC)

Q96–Q110 · Decorators, communication, and lifecycle

Q096🟢

What is Lightning Web Component (LWC)?

LWC is Salesforce's modern JavaScript framework for building custom UI components — built on native Web Components standards (not a proprietary framework), making it fast, lightweight, and closer to standard web development.

🔑 Key Points

LWC coexists with the older Aura framework and can even be embedded within Aura components for backward compatibility. LWC components can be placed on Record Pages, App Pages, Home Pages, or embedded in Experience Cloud sites via Lightning App Builder.

🌍 XYZ Company / Example

A developer builds a custom LWC dashboard showing a Contact's related Opportunities in a custom card layout with sorting and filtering — something the standard related list can't provide out of the box. Once you're comfortable with LWC basics, our Headless 360 / MCP course covers advanced integration patterns.

🎤 “LWC is Salesforce's modern, standards-based JavaScript framework for building fast, reusable custom UI components on the Lightning platform.”

Q097🟠

What is the difference between Aura Components and LWC?

Aura is Salesforce's older, proprietary component framework. LWC is the newer framework built on native Web Component browser standards — generally faster, lighter-weight, and closer to standard modern JavaScript development.

🔑 Key Points

LWC has better performance since it leverages the browser's native custom element support rather than Aura's abstraction layer. Salesforce recommends building all new development in LWC; Aura is mainly maintained for legacy compatibility (and LWC can be embedded inside Aura when needed for interop).

🌍 XYZ Company / Example

A team building a brand-new custom UI feature in 2026 builds it entirely in LWC. If they need it to interact with an older Aura-based component still in use, they wrap the LWC inside a thin Aura component for that specific interop scenario.

🎤 “Aura is Salesforce's older proprietary framework; LWC is the modern, standards-based framework recommended for all new development due to better performance.”

Q098🟢

What are the three main files in an LWC bundle?

An LWC bundle centers on three core files sharing the same name: a JavaScript file (.js, the component's logic), an HTML file (.html, the template/markup), and a metadata configuration file (.js-meta.xml, exposes the component to App Builder/Experience Builder).

🔑 Key Points

Optional additional files can include a CSS file (.css, component-scoped styling) and an SVG file (custom icon). The .js-meta.xml file is what makes a component visible/draggable in Lightning App Builder — without it, the component can only be used programmatically by other components.

🌍 XYZ Company / Example

A component called 'contactCard' has: contactCard.js (logic), contactCard.html (template), contactCard.js-meta.xml (exposure config), and optionally contactCard.css (styling) — all bundled together under a folder named contactCard.

🎤 “An LWC bundle's three core files are the JavaScript (.js), HTML template (.html), and metadata config (.js-meta.xml) — with CSS being an optional fourth file.”

Q099🟠

What is @api decorator used for?

The @api decorator exposes a property or method as PUBLIC — meaning it can be set from outside the component (like from a parent component, or from Lightning App Builder as a configurable property).

🔑 Key Points

Public properties decorated with @api are how a parent component passes data DOWN to a child component (similar to props in React). Public methods decorated with @api can be called directly by a parent component holding a reference to the child.

🌍 XYZ Company / Example

A child component 'contactCard' exposes @api recordId — the parent component (or App Builder) sets this recordId value, telling the child exactly which Contact record to display.

🎤 “@api exposes a property or method as public, allowing it to be set or called from outside the component — most commonly used to pass data from a parent to a child.”

Q100🟠

What is @track decorator used for?

The @track decorator (largely legacy now) marks a property as reactive, meaning the UI automatically re-renders when that property's value changes. In modern LWC, primitive fields are reactive by default WITHOUT @track — it's now only needed for tracking changes to nested properties within objects or arrays.

🔑 Key Points

This is a common 'gotcha' interview question since LWC's reactivity behavior changed after Spring '20 — simple variables (String, Number, Boolean) don't need @track anymore, but if you mutate a NESTED field inside an object/array, you still need @track to force the UI to notice that internal change.

🌍 XYZ Company / Example

A component has 'name' (String) — no @track needed, changing it auto-updates the UI. But a component has 'contact = {name: '', tags: []}' — if you push a new tag into contact.tags, you need @track contact to force the UI to detect that nested array change.

🎤 “@track makes a property reactive for UI re-rendering — no longer needed for simple primitives (reactive by default), but still required for detecting changes to nested object/array properties.”

Q101🟠

What is @wire decorator used for?

The @wire decorator connects a component to Salesforce data — automatically calling an Apex method or a Lightning Data Service adapter (like getRecord) and reactively re-invoking it whenever its reactive parameters change, without manual imperative calls.

🔑 Key Points

@wire can be used as a property (data streams in automatically) or a function (more control, gives access to both data and error explicitly). It's the declarative, reactive way to fetch data — contrasted with imperative Apex calls which you trigger manually (e.g., in response to a button click).

🌍 XYZ Company / Example

A component uses '@wire(getContactList) contacts;' — as soon as the component loads, it automatically calls the Apex method getContactList and populates the 'contacts' property with results, re-running automatically if any wired parameter changes.

🎤 “@wire declaratively connects a component to data (Apex methods or Lightning Data Service), automatically calling and re-calling it in response to reactive parameter changes.”

Q102🟠

How does a Parent component pass data to a Child component in LWC?

A Parent passes data to a Child by setting a public property (decorated with @api on the child) as an HTML attribute in the parent's template — data flows DOWN the component hierarchy, one direction only, just like passing props in modern frontend frameworks.

🔑 Key Points

In the parent's HTML template, you'd write something like <c-child-component record-id={someValue}></c-child-component> — camelCase properties become kebab-case HTML attributes. The child receives this via its own @api recordId property.

🌍 XYZ Company / Example

A parent 'contactList' component loops through Contacts and for each one renders <c-contact-card contact={con}></c-contact-card> — passing each individual Contact record down into a reusable child card component.

🎤 “Parent-to-child data flows through public @api properties set as HTML attributes in the parent's template — a one-way, top-down data flow pattern.”

Q103🟠

How does a Child component send data back to a Parent in LWC?

A Child sends data UP to a Parent by dispatching a Custom Event — the child fires the event using this.dispatchEvent(new CustomEvent(...)), and the parent listens for it in its template using an event handler attribute.

🔑 Key Points

This is the reverse direction of the @api property pattern — since data can't flow upward through properties, Custom Events are the standard mechanism. The event can carry data in its 'detail' property, which the parent's handler function can then read.

🌍 XYZ Company / Example

A child 'contactCard' component dispatches a CustomEvent('select', {detail: this.recordId}) when clicked. The parent's template listens with <c-contact-card onselect={handleSelect}>, and its handleSelect(event) method reads event.detail to get the selected recordId.

🎤 “Child-to-parent communication uses Custom Events — the child dispatches an event (optionally carrying data), and the parent listens for it in its template with an event handler.”

Q104🟠

What is an Event in LWC (CustomEvent)?

A CustomEvent is the standard Web Component mechanism LWC uses for components to communicate — most commonly for child-to-parent communication, though it can also be used for sibling communication via a shared parent or a Lightning Message Service for cross-hierarchy communication.

🔑 Key Points

Created with 'new CustomEvent(eventName, {detail: dataPayload})' and fired with 'this.dispatchEvent(event)'. Events bubble by default only if explicitly configured with {bubbles: true} — by default they only reach the immediate parent listening for that specific event name.

🌍 XYZ Company / Example

A 'ratingWidget' child component dispatches a CustomEvent('ratingchange', {detail: {rating: 5}}) whenever a user clicks a star — any parent listening via onratingchange={handler} receives that rating value in the event's detail property.

🎤 “CustomEvent is the Web Component-standard mechanism for component communication in LWC, primarily used to send data from a child component back up to its parent.”

Q105🟠

What is connectedCallback() lifecycle hook used for?

connectedCallback() is a lifecycle hook that fires when a component is inserted into the DOM — commonly used to initialize data, call an Apex method imperatively, or set up initial component state right as the component becomes active.

🔑 Key Points

Other key lifecycle hooks: constructor() (fires first, before connectedCallback, limited DOM access), renderedCallback() (fires after every render, can fire multiple times — be careful of infinite loops here), and disconnectedCallback() (fires when component is removed from DOM, good for cleanup like clearing timers).

🌍 XYZ Company / Example

A component needs to load data as soon as it appears on the page — it calls an imperative Apex method inside connectedCallback() to fetch and populate that data immediately when the component is first rendered.

🎤 “connectedCallback() fires when a component is inserted into the DOM, commonly used for initialization logic like fetching initial data.”

Q106🟢

What is the Lightning Design System (SLDS)?

SLDS (Salesforce Lightning Design System) is Salesforce's official CSS framework and design language, providing pre-built styles, icons, and components that give custom UI a consistent, native Salesforce look and feel.

🔑 Key Points

SLDS includes utility classes (like slds-m-around_medium for margin spacing), pre-styled components (buttons, cards, modals), and the Lightning Design System icon set — all usable directly in LWC templates without any custom CSS needed for standard-looking UI.

🌍 XYZ Company / Example

Instead of writing custom CSS for spacing and button styling, a developer uses SLDS utility classes directly in the LWC template: <button class='slds-button slds-button_brand'>Save</button> — automatically matching Salesforce's native design.

🎤 “SLDS is Salesforce's official CSS framework providing pre-built styles, icons, and components for consistent, native-looking custom UI.”

Q107🟠

Can LWC call an Apex method? How?

Yes, two ways: Wire Adapter (@wire — declarative, automatic, reactive) or Imperative call (manually invoking the Apex method, typically inside a JavaScript function like a button click handler, using .then()/.catch() for the returned Promise).

🔑 Key Points

The Apex method must be decorated with @AuraEnabled(cacheable=true) for wire usage, or just @AuraEnabled for imperative calls (cacheable methods are read-only and can be cached; non-cacheable methods can perform DML). Import the method at the top of the JS file using: import methodName from '@salesforce/apex/ClassName.methodName'.

🌍 XYZ Company / Example

A 'Save' button's click handler imperatively calls an Apex method to insert a record: saveRecord({data: this.formData}).then(result => {...}).catch(error => {...}) — since inserting data requires an explicit user action, not automatic wiring.

🎤 “LWC calls Apex either declaratively via @wire (automatic, reactive, cacheable) or imperatively via a manual JavaScript function call — chosen based on whether the call should be automatic or user-triggered.”

Q108🟠

What is imperative Apex call vs wire Apex call?

A Wire call automatically executes when the component loads and re-executes reactively when its parameters change — it's declarative and best for simply displaying data. An Imperative call is manually triggered in JavaScript code (like inside a button click handler) and gives you full control over WHEN it executes.

🔑 Key Points

Wire calls MUST use @AuraEnabled(cacheable=true) Apex methods (read-only, no DML allowed). Imperative calls can use both cacheable and non-cacheable methods, making them necessary whenever you need to perform DML (insert/update/delete) triggered by a user action.

🌍 XYZ Company / Example

Displaying a list of related Contacts on page load uses a wire call (automatic). Submitting a form that inserts a new Case when a user clicks 'Submit' uses an imperative call (must happen only on that specific click, and needs to perform DML).

🎤 “Wire calls run automatically and reactively for read-only data display; Imperative calls run on-demand from JavaScript code and support DML operations triggered by user actions.”

Q109🟢

What is a Lightning App Builder used for?

Lightning App Builder is Salesforce's drag-and-drop, point-and-click tool for building custom pages — Record Pages, App Pages, and Home Pages — by arranging standard and custom Lightning components (including LWC) visually without code.

🔑 Key Points

Admins use App Builder to customize what appears on a Record Page for different Record Types or Profile-based Lightning App page assignments — including placing custom LWC components (if they have a properly configured .js-meta.xml exposing them) alongside standard Salesforce components.

🌍 XYZ Company / Example

An admin drags a custom 'accountTeamCard' LWC component onto the Account Record Page in Lightning App Builder, positioning it alongside standard Related List and Activity components, all without writing a single line of code.

🎤 “Lightning App Builder is Salesforce's no-code, drag-and-drop tool for assembling Record Pages, App Pages, and Home Pages from standard and custom Lightning components.”

Q110🟠

Can you add an LWC to a Record Page? How?

Yes — as long as the LWC's .js-meta.xml file has isExposed set to true and targets lightning__RecordPage listed, the component becomes available in Lightning App Builder's component list, ready to drag onto any Record Page.

🔑 Key Points

You can also expose target-specific configuration (like allowing an admin to set the recordId or other @api properties directly through App Builder's UI, using <targetConfigs> in the meta.xml), giving admins configuration control without touching code.

🌍 XYZ Company / Example

A developer builds 'contactActivityTimeline' LWC, sets isExposed=true and targets=lightning__RecordPage in its meta.xml, then an admin drags it onto the Contact Record Page layout via App Builder — no additional deployment needed after that first setup.

🎤 “An LWC becomes addable to Record Pages by setting isExposed=true and targeting lightning__RecordPage in its .js-meta.xml configuration file — after which admins can drag it on visually in App Builder.”

🔌

Integration & Miscellaneous

Q111–Q125 · APIs, packages, and platform essentials

Q111🟢

What is an API in Salesforce context?

An API (Application Programming Interface) in Salesforce is a way for external systems to communicate with Salesforce programmatically — to read, create, update, or delete data, or invoke business logic, without using the standard UI.

🔑 Key Points

Salesforce offers multiple APIs for different use cases: REST API (lightweight, most common for web/mobile), SOAP API (enterprise, XML-based), Bulk API (large data volumes), Streaming API (real-time event notifications), and Metadata API (deploying configuration/metadata).

🌍 XYZ Company / Example

An external e-commerce website uses Salesforce's REST API to create a new Order record in Salesforce every time a customer completes checkout on the website.

🎤 “An API lets external systems communicate programmatically with Salesforce — reading, writing, or invoking logic without going through the standard user interface.”

Q112🟠

What is REST API vs SOAP API?

REST API is lightweight, uses standard HTTP methods (GET/POST/PATCH/DELETE) and JSON, making it easier and faster to work with for most modern integrations. SOAP API is XML-based, more rigid/formal with a strict WSDL contract, and typically used in enterprise systems requiring stronger typing and formal contracts.

🔑 Key Points

REST API is generally preferred for new integrations — mobile apps, modern web apps — due to its simplicity and JSON's lighter payload size compared to XML. SOAP is still common in legacy enterprise integrations (like older ERP or ESB middleware systems) that were built around WSDL contracts.

🌍 XYZ Company / Example

A modern mobile app syncing Case data uses REST API for its lightweight JSON responses. A legacy enterprise SAP integration built years ago continues using SOAP API since that's what the original middleware was configured for.

🎤 “REST API is lightweight, JSON-based, and preferred for modern integrations; SOAP API is XML-based, contract-driven, and more common in legacy enterprise systems.”

Q113🟠

What is a Connected App used for?

A Connected App is a framework that enables an external application to integrate with Salesforce using APIs, OAuth-based authentication, and defined security policies — essentially the 'front door' configuration for any external system connecting to your org.

🔑 Key Points

Configured under Setup → App Manager → New Connected App. Defines the OAuth Scopes (what the external app is allowed to do), Callback URL, and Consumer Key/Secret used for authentication. Also where session policies (like IP restrictions or refresh token behavior) can be set specifically for that integration.

🌍 XYZ Company / Example

A company building a custom mobile app that logs into Salesforce creates a Connected App, which generates a Consumer Key and Secret the mobile app uses to authenticate via OAuth and access Salesforce data securely.

🎤 “A Connected App is the configuration framework that allows an external application to securely integrate with Salesforce via OAuth-based authentication and defined API permissions.”

Q114🟠

What is OAuth in Salesforce?

OAuth is the industry-standard authorization protocol Salesforce uses to let external applications access a user's Salesforce data securely — WITHOUT that external app ever seeing or storing the user's actual username and password.

🔑 Key Points

Common OAuth flows: Web Server Flow (server-side apps), User-Agent Flow (client-side/mobile apps), and JWT Bearer Flow (server-to-server integrations without user interaction). The external app receives an Access Token (and often a Refresh Token) after successful authorization, which it uses for subsequent API calls.

🌍 XYZ Company / Example

A third-party app wants to read a user's Salesforce Calendar — instead of asking for their password, it redirects them to Salesforce's login page, the user approves access, and Salesforce returns an Access Token the app then uses for all future API calls.

🎤 “OAuth is the secure authorization protocol enabling external apps to access Salesforce data on a user's behalf using tokens, without ever handling the user's actual password.”

Q115🟠

What is a Named Credential?

A Named Credential stores the endpoint URL and authentication details (username/password, OAuth, or certificate) for an external system in one secure, reusable configuration — so Apex callout code never needs to hardcode credentials directly.

🔑 Key Points

Using a Named Credential in a callout means Salesforce automatically handles authentication headers for you (e.g., 'callout:My_Named_Credential/api/endpoint') — improving both security (no hardcoded secrets in code) and maintainability (update credentials in one place, not scattered across multiple Apex classes).

🌍 XYZ Company / Example

Instead of hardcoding an API key directly inside an Apex HTTP callout class, a developer creates a Named Credential 'Stripe_API' storing the authentication details — the Apex code simply references 'callout:Stripe_API' and Salesforce handles the rest securely.

🎤 “A Named Credential securely stores an external system's endpoint and authentication details in one reusable place, keeping credentials out of hardcoded Apex code.”

Q116🟢

What is Salesforce AppExchange?

Salesforce AppExchange is Salesforce's official marketplace for pre-built apps, components, and consulting services — built by Salesforce partners and third-party developers — that can be installed into any Salesforce org to extend its functionality.

🔑 Key Points

Apps range from free to paid, and can be managed packages (locked, upgradeable by the publisher) or unmanaged packages (fully open, editable after install but no auto-updates). Popular examples include DocuSign, Conga, and various industry-specific solution packages.

🌍 XYZ Company / Example

Instead of building an e-signature feature from scratch, a company installs DocuSign for Salesforce directly from AppExchange, saving months of custom development time.

🎤 “AppExchange is Salesforce's official marketplace for installing pre-built apps and components, saving significant custom development time and effort.”

Q117🟢

What is Chatter?

Chatter is Salesforce's built-in enterprise social collaboration tool — allowing users to post updates, follow records, comment, and share files directly within Salesforce, similar to an internal social network.

🔑 Key Points

Users can follow specific records (like an Account or Opportunity) to get a feed of updates about it. Chatter Groups allow team-based collaboration spaces. Chatter also powers the Case Feed interface used heavily in Service Cloud.

🌍 XYZ Company / Example

A Sales Rep posts a Chatter update on a big Opportunity announcing it just moved to 'Negotiation' stage — everyone following that Opportunity (including their manager) instantly sees the update in their feed.

🎤 “Chatter is Salesforce's built-in social collaboration tool for posting updates, following records, and enabling internal team communication directly within the platform.”

Q118🟠

What is a Custom Metadata Type? How is it different from Custom Setting?

Custom Metadata Type stores configuration data as actual METADATA (deployable through Change Sets/packages just like any other metadata component) — while Custom Setting stores configuration data as regular application DATA (not deployable as metadata, must be manually re-entered or data-loaded per org).

🔑 Key Points

Custom Metadata Types are the modern best practice for storing configuration values (like API endpoints, feature flags, or mapping tables) since they migrate automatically between Sandbox and Production with a deployment — Custom Settings require manual re-entry or a separate data migration step in each environment.

🌍 XYZ Company / Example

A company storing a list of country-to-currency mappings uses a Custom Metadata Type 'Currency_Mapping__mdt' — when they deploy from Sandbox to Production, those mapping records deploy automatically along with the deployment, unlike a Custom Setting which would need re-entering.

🎤 “Custom Metadata Types are deployable as metadata (auto-migrate between environments); Custom Settings are stored as data and must be manually re-entered or migrated separately per org.”

Q119🟢

What is a Custom Label used for?

Custom Labels store text values (like UI messages, error text, or button labels) that are translatable and deployable as metadata — commonly used to avoid hardcoding text strings directly in Apex or LWC code, especially for multi-language orgs.

🔑 Key Points

Custom Labels support Translation Workbench, meaning the same label can automatically display in different languages based on the user's language setting — without needing separate code paths for each language.

🌍 XYZ Company / Example

Instead of hardcoding the string 'Please contact support' directly in an LWC component, a developer creates a Custom Label 'Contact_Support_Message' — allowing that exact text to be translated into Spanish, French, etc. for different users automatically.

🎤 “Custom Labels store translatable, deployable text values used to avoid hardcoding UI strings directly in code, especially important for multi-language Salesforce orgs.”

Q120🟠

What is Salesforce CLI (SFDX) used for?

Salesforce CLI (also called SFDX) is a command-line tool for developers to create, manage, and deploy Salesforce projects — enabling source-driven development, scratch org creation, automated testing, and CI/CD pipeline integration.

🔑 Key Points

Common commands include creating Scratch Orgs (temporary, disposable development orgs), deploying/retrieving metadata, running Apex tests from the command line, and converting between source format and metadata API format. It's the foundation of modern Salesforce DevOps practices.

🌍 XYZ Company / Example

A development team uses Salesforce CLI to spin up a fresh Scratch Org for each new feature branch, push their source code into it for testing, run automated Apex tests via command line, then tear the Scratch Org down when done — all without touching a persistent Sandbox.

🎤 “Salesforce CLI (SFDX) is a command-line development tool enabling source-driven development, scratch orgs, automated deployment, and CI/CD integration for modern Salesforce DevOps.”

Q121🟠

What is a Managed Package vs Unmanaged Package?

A Managed Package is locked/protected code distributed (often via AppExchange) that the installing org cannot directly edit — the publisher controls updates and can push upgrades. An Unmanaged Package is fully open and editable after install, but has no built-in upgrade mechanism.

🔑 Key Points

Managed Packages use a unique namespace prefix on all their components (preventing naming conflicts across orgs) and are the standard way ISVs (Independent Software Vendors) distribute commercial products on AppExchange. Unmanaged Packages are more commonly used for sharing open-source templates or one-time starter code.

🌍 XYZ Company / Example

A company buys a commercial CPQ solution from AppExchange — it installs as a Managed Package they can configure but not directly edit the underlying Apex code, and they receive automatic updates from the vendor over time.

🎤 “Managed Packages are locked, vendor-controlled, upgradeable, and namespaced (typical for commercial AppExchange products); Unmanaged Packages are fully open and editable but have no built-in upgrade path.”

Q122🟠

What is Multi-Currency support in Salesforce?

Multi-Currency is an org-level feature (enabled by Salesforce Support upon request) that allows an org to record and report on transactions in multiple currencies — each record can have its own currency, and amounts can be converted to a Corporate Currency for consolidated reporting.

🔑 Key Points

Once enabled, Currency-type fields become currency-aware (each record has a CurrencyIsoCode field). Salesforce maintains Dated Exchange Rates for historical accuracy in reporting, alongside standard (static) Exchange Rates for simpler conversions. This feature CANNOT be disabled once turned on.

🌍 XYZ Company / Example

A global company with sales teams in the US, UK, and India enables Multi-Currency so a Deal closed in India shows in INR on that record, but rolls up into a consolidated USD figure on executive dashboards using the Corporate Currency conversion.

🎤 “Multi-Currency support lets an org record transactions in multiple currencies per record while still consolidating reporting into a single Corporate Currency using configured exchange rates.”

Q123🟢

What is Person Account?

A Person Account is a special record type that combines Account and Contact information into a SINGLE record — used when a business sells directly to individual consumers (B2C) rather than to companies (B2B), where the standard Account-Contact separation doesn't make sense.

🔑 Key Points

Person Accounts must be enabled by Salesforce Support (also cannot be disabled once turned on) and behave like a hybrid — they have Account-level fields (like Industry) AND Contact-level fields (like Email, Birthdate) all on one record, avoiding the need to create a separate 'shell' Account for every individual customer.

🌍 XYZ Company / Example

A subscription box company selling directly to individual consumers uses Person Accounts so each customer is ONE record (not an Account + a separate Contact), simplifying data model and reporting for a B2C business model.

🎤 “A Person Account merges Account and Contact data into a single record, designed for B2C businesses selling directly to individual consumers rather than companies.”

Q124🟢

What is Einstein / Agentforce in Salesforce (fresher-level awareness)?

Einstein is Salesforce's umbrella brand for AI features across the platform (predictions, recommendations, generative AI). Agentforce is Salesforce's newer autonomous AI agent platform — capable of taking actions (not just suggesting them) across Sales, Service, and other clouds with configurable guardrails.

🔑 Key Points

At a fresher level, you're not expected to build these — just understand the distinction: Einstein features (like Einstein Case Classification or Einstein Prediction Builder) mostly assist/predict, while Agentforce agents can autonomously execute multi-step actions end-to-end with human oversight configured by admins.

🌍 XYZ Company / Example

A support team uses Einstein Case Classification to auto-suggest a Case's Type and Priority (assistive), while a separate Agentforce Service Agent can autonomously resolve simple customer inquiries end-to-end without a human agent involved at all. Want to test your Agentforce knowledge? Try our free Agentforce MCQ practice.

🎤 “Einstein is Salesforce's broad AI feature brand (predictions/recommendations); Agentforce is the newer autonomous AI agent platform capable of independently executing actions across the CRM.”

Q125🟢

What is the Salesforce release cycle?

Salesforce ships three major releases per year — Spring, Summer, and Winter — each bringing new features, platform updates, and occasional deprecations, automatically applied to every org on a rolling schedule.

🔑 Key Points

Each release goes through a Sandbox preview period before hitting Production, giving admins/developers time to test new features and check for breaking changes. Release notes are published in advance, and it's considered a best practice to review them each cycle, especially for orgs with heavy customization.

🌍 XYZ Company / Example

Before the Winter '27 release hits Production, an admin tests their org's automation and custom code against the new release in a Sandbox (which gets it early) to catch any compatibility issues before their live users are affected.

🎤 “Salesforce releases three major platform updates per year (Spring, Summer, Winter), rolling out to Sandboxes first for testing before reaching Production orgs automatically.”

📚 Keep Going — Explore More on SFInterviewPro.com:

→ All Free Salesforce Courses 2026 — Agentforce, Data Cloud, LWC, BA & Admin Zero to Hero
→ Salesforce Interview Questions Hub 2026 — every topic, every level
→ Practice Zone — free & premium timed MCQ quizzes
→ Apex Triggers Free MCQ Practice — go deeper once you clear the basics here
→ Agentforce Free MCQ Practice — test your AI agent knowledge
→ Headless 360 / MCP Course — for when you're ready to go beyond fresher level
→ 6 Years Experience Developer Interview Questions — see where this journey leads

By SF Interview Pro

Salesforce Interview Prep Team

Practical Q&A by working Salesforce professionals · LWC, Apex, Data Cloud & AI

About Us ↗

☕

☕ Enjoyed this article?

SF Interview Pro is 100% free and maintained by a Salesforce professional. No ads, no paywalls, and no signup required. If this guide helped you prepare for an interview, earn a certification, or grow your Salesforce career, consider buying me a coffee! ☕💜

🇮🇳 UPI (India)

Pay by QR

GPay · PhonePe · Paytm · BHIM

🌎 International

PayPal QR Code to support sfinterviewpro

Pay via PayPal ↗

Scan or tap to pay

New interview questions every week

Follow for fresh Salesforce Q&A, free courses, and real interview experiences — straight from the trenches.