75 Salesforce Interview Questions Asked at Capgemini (2026) — L1 & L2 Rounds | SF Interview Pro

🏢 Company-Specific Interview Prep 2026

Salesforce Interview Questions
Asked at Capgemini 2026

58 real Salesforce interview questions asked at Capgemini across L1 and L2 technical rounds — Apex, Triggers, LWC, Flows, Integration, Security & Sharing, fully explained with code and real-world examples. 100% Free, no signup.

Questions

Topics

L1+L2

Rounds Covered

100%

Free

Browse All Topics → TCS / Cognizant / Accenture →

Preparing for a Capgemini Salesforce interview? This guide compiles 58 real questions gathered from actual L1 and L2 candidate interviews at Capgemini, covering record sharing & security, Apex triggers, governor limits, Lightning Web Components, Flows, and integration patterns. Every answer follows our 7-step format — direct answer, why it works, code example, real-world scenario, key interview points, and a one-line answer you can say directly in the room. If you're prepping for 6+ years of experience level interviews, also check our 100 Senior Developer Questions guide.

🔗 Related Interview Prep

⚙️ Apex Triggers (120+ Q&A) 💻 LWC Questions 🔍 SOQL Questions (81+) 🔄 Flows & Automation 🔗 Integration 🔒 Record Sharing 🏆 For Experienced (5+ Yrs) 🏢 TCS / Cognizant / Accenture 🎓 LWC Zero to Hero Course 🤖 Agentforce Course 📝 Practice Zone (2,244 MCQs) 🏆 150 Advanced Questions

📋 Capgemini Interview Pattern (L1 / L2)

Technical Round 1 (45-60 mins)

Core Apex (triggers, governor limits, async), LWC fundamentals (lifecycle hooks, decorators, communication), field-level security, sharing model. Mix of theory + live coding.

Technical Round 2 (45-60 mins)

Deeper LWC (pub-sub via Message Channel, toast notifications, child-to-parent), integration patterns, project-specific scenario questions, code-writing exercises.

Scenario / Managerial Round

Real project scenarios — data security edge cases, deployment process, dataloader rollback situations, sharing troubleshooting. Tests hands-on experience, not just theory.

📋 Topics Covered — 58 Questions

🔒 Security & Sharing (Q1-Q12) ⚙️ Apex, Triggers & Governor Limits (Q13-Q24) ⏳ Async & Batch Apex (Q25-Q31) 💻 LWC Fundamentals (Q32-Q42) 🔀 LWC Communication & Navigation (Q43-Q49) 🔄 Flows & Automation (Q50-Q54) 🔗 Integration & Named Credentials (Q55-Q61) 🔍 SOQL & Reports (Q62-Q66) 🎯 Scenario-Based Questions (Q67-Q75)

🔒 Section 1 — Security & Sharing Model

Q1–Q12 · Most Asked Topic at Capgemini — Every Round

How many ways can you make a field mandatory in Salesforce?

✅ Direct Answer

Five ways: 1) Field-level "Required" checkbox at field definition (org-wide, all page layouts, all entry points including API). 2) Page Layout "Required" attribute (layout-specific only, doesn't block API inserts). 3) Validation Rule using ISBLANK() or ISNULL() (most flexible — supports conditional logic). 4) Required attribute on a Flow Screen input component. 5) Apex trigger using addError() (last resort, for logic too complex for a Validation Rule).

💡 Why?

Each method enforces at a completely different layer of the stack, and interviewers ask this specifically to see if you understand WHERE each one applies. Field-level required is the strictest — it blocks the UI, the REST/SOAP API, and Data Loader simultaneously, because it's baked into the field's metadata definition. Page layout required only affects users editing through that specific layout in the UI — a Data Loader bulk insert completely bypasses it, which is a common gotcha in data migration projects. Validation Rules sit in between: they apply everywhere DML happens (UI, API, Flow, Apex) but let you make the requirement conditional — e.g., "Website is required only when Industry = Technology" — something a simple field-level checkbox can't express.

🌍 Real World Example

XYZ Company had a field-level required checkbox on Account.Phone — this blocked every insert path uniformly, including nightly Data Loader jobs from their ERP, which sometimes legitimately didn't have a phone number yet. Switching to a Validation Rule (require Phone only when Type = 'Customer') let the ERP sync continue for prospect records while still enforcing the rule for active customers — this is exactly the kind of conditional nuance that makes Validation Rules the most commonly used method in real projects.

🔑 Key Points for Interviewer

Field-level required: strictest, applies everywhere including API and Data Loader
Page layout required: UI only, bypassed by Data Loader/API — common data quality gap
Validation Rule: conditional required logic, most commonly used in production orgs
Flow Screen required: only within that guided process, doesn't affect direct record edits
Trigger addError(): only for complex logic (e.g., requiring a related record to exist) Validation Rules can't express

🎤 One-Line Answer

"Five ways: field-level required (strictest, all entry points), page layout required (UI only), Validation Rule (conditional logic, most common), Flow Screen required, and Apex trigger addError() for complex cases."

Can we make a field mandatory via a trigger? How?

✅ Direct Answer

Yes — in a before insert/before update trigger, check if the field is null/blank and call fieldName.addError('message') on the specific SObject field. This blocks the save with a field-level error, exactly like a Validation Rule, but allows more complex conditional logic (e.g., checking related records via SOQL) that a declarative Validation Rule formula can't express.

💡 Why?

Validation Rules operate purely on formula logic evaluated against the current record and its direct parent relationships — they can't run a SOQL query. If your "required" logic depends on counting related child records, checking a value from an unrelated object, or complex multi-step conditions, only Apex can express that. addError() called on a specific field (rather than the record) is important because it highlights that exact field in the UI with a red border — the same UX as a native required field or Validation Rule error.

🌍 Real World Example

trigger AccountTrigger on Account (before insert, before update) { for(Account acc : Trigger.new) { if(acc.Industry == 'Technology' && String.isBlank(acc.Website)) { acc.Website.addError('Website is required for Technology accounts'); } } }

XYZ Company needed "Contract_Number__c is required only if there is at least one Closed Won Opportunity on this Account" — counting related Opportunities is impossible in a Validation Rule formula, so this had to move to a before-update trigger that queries related Opportunities and calls addError() conditionally.

🔑 Key Points for Interviewer

Use before trigger — blocks before DML commits, no wasted DML operation
addError() on the field highlights that exact field in UI (better UX than a record-level error)
Prefer Validation Rules when logic is simple — triggers only when it needs SOQL/complex logic
Trigger-based mandatory checks also apply uniformly to API/Data Loader inserts, just like Validation Rules

🎤 One-Line Answer

"Yes — in a before trigger, check if the field is blank and call field.addError() — use this only when the required-logic needs SOQL or complexity beyond what a Validation Rule can express."

What are the different access levels (record access) in Salesforce?

✅ Direct Answer

Private, Public Read Only, Public Read/Write, Public Read/Write/Transfer (available on Leads and Cases only), and Controlled by Parent — set as Organization-Wide Defaults (OWD) per object. These form the restrictive baseline and are then extended — never restricted further — via Role Hierarchy, Sharing Rules, and Manual Sharing.

💡 Why?

OWD is the single most important setting in Salesforce's security model because everything downstream builds on top of it — you always design OWD as the MOST restrictive setting the business genuinely needs, then open up access with more targeted mechanisms. Getting this backward (starting permissive and trying to restrict later) is a classic implementation mistake, because sharing mechanisms in Salesforce can only ADD access on top of OWD, never subtract from it.

🌍 Real World Example

XYZ Company set Opportunity OWD to Private because sales reps shouldn't see each other's deals by default. Sales Managers then get visibility through Role Hierarchy (they sit above their reps). A cross-functional "Enterprise Deals" sharing rule opens specific high-value Opportunities to the Legal and Finance teams. If OWD had instead been set to Public Read/Write from the start, none of that granular control would have been achievable — everyone would see everything and there'd be no way to dial it back without a painful re-architecture.

🔑 Key Points for Interviewer

Private: only owner + role hierarchy above + admins with "View/Modify All"
Public Read Only: everyone can view, only owner (+ hierarchy) can edit
Public Read/Write: everyone can view and edit
Controlled by Parent: child inherits access from Master-Detail parent — no independent OWD setting
OWD is the baseline — every other sharing mechanism (roles, rules, manual) only adds access on top

🎤 One-Line Answer

"OWD access levels: Private, Public Read Only, Public Read/Write, Public Read/Write/Transfer, and Controlled by Parent — set as the restrictive baseline, then opened up via roles, sharing rules, and manual sharing."

⚙️ Section 2 — Apex, Triggers & Governor Limits

Q13–Q24 · Live Coding Common

Q13

What are governor limits in Salesforce, and can you handle them in Apex using try-catch?

✅ Direct Answer

Governor limits cap resource usage per transaction to protect the multi-tenant platform (100 SOQL queries, 150 DML statements, 6 MB heap, 10,000 ms CPU time, and more). No — you CANNOT catch a governor limit exception (LimitException) with try-catch and continue execution — it's a fatal, uncatchable error that immediately rolls back the entire transaction. The only real solution is to never hit the limit in the first place — bulkify your code, and proactively check the various Limits.getLimitX() methods before attempting risky operations.

💡 Why?

This is a genuinely important trick question because it reveals whether a candidate understands the difference between "handleable" exceptions and platform-level circuit breakers. A DmlException or QueryException from a bad record IS catchable and recoverable mid-transaction — but a LimitException means the platform itself has determined the transaction is misbehaving in a way that could impact other tenants sharing the same infrastructure, so it forces an immediate, non-negotiable rollback. There's no graceful degradation path once you've hit the wall.

🌍 Real World Example

A junior developer at XYZ Company wrapped a loop containing SOQL in a try-catch, assuming that if it hit the 100-query limit on record 101, the catch block would let processing continue for the remaining records with a logged warning. Instead, the entire transaction — including the 100 successfully processed records — rolled back completely, because LimitException bypasses normal catch blocks. The real fix was bulkifying the loop to use a single SOQL query with an IN clause instead of one query per record.

🔑 Key Points for Interviewer

LimitException is NOT catchable with try-catch — it aborts the entire transaction, including prior successful work
Prevention is the only real strategy: bulkify, and use Limits.getQueries()/getDMLStatements() to monitor proactively
Design defensively: check remaining limit BEFORE the risky operation, not after
This differs from ordinary exceptions (DmlException, QueryException) which ARE catchable and recoverable

🎤 One-Line Answer

"No — governor limit exceptions can't be caught and recovered from; they immediately abort the transaction. The only real defense is prevention: bulkify code and proactively check Limits.getX() methods before risky operations."

⏳ Section 3 — Async & Batch Apex

Q25–Q31 · Advanced

Q25

What is Asynchronous Apex? Name the types and when to use each.

✅ Direct Answer

Asynchronous Apex runs in a separate thread/transaction outside the current request, with its own fresh set of governor limits. Four types: @future (simple fire-and-forget, primitive parameters only), Queueable (chainable, accepts SObjects, exposes a monitorable Job ID), Batch Apex (processes millions of records in manageable chunks), Scheduled Apex (time-based trigger, most commonly used just to launch a Batch job on a schedule).

💡 Why?

Choosing the right async type is a genuine architecture decision, not just trivia — @future is the simplest but most limited (no chaining, no SObject params, no monitoring), which is why Queueable has largely superseded it in modern Apex. Batch is reserved specifically for volumes too large to fit within a single transaction's governor limits (millions of records), while Scheduled Apex is purely about WHEN something runs, not HOW MUCH it processes — which is why it's almost always paired with Batch rather than doing heavy processing directly in its own execute() method.

🌍 Real World Example

XYZ Company uses: a nightly Scheduled Apex job (fires at 2 AM) that launches a Batch Apex class to recalculate scores across 2 million Account records; a Queueable chain to process payment-then-confirmation-email in guaranteed sequence when an Order closes; and a legacy @future method for a fire-and-forget audit log callout where failure doesn't matter and no chaining is needed.

🎤 One-Line Answer

"Async Apex runs outside the current transaction with fresh governor limits — @future for simple fire-and-forget, Queueable for chainable SObject-based jobs, Batch for millions of records, Scheduled for time-based triggers."

Q26

Why can't we call other async operations from the start() or execute() method in Batch Apex?

✅ Direct Answer

start() and execute() already run in an asynchronous context. Salesforce restricts nesting async-within-async at that level specifically to prevent runaway chains that could exhaust the org's 24-hour async execution limit (250,000 executions per rolling day). You CAN enqueue a Queueable from execute() (that's explicitly allowed), but you cannot call Database.executeBatch() to start a brand-NEW batch job from execute() — that's only permitted from finish(), which runs once after the entire current batch job has fully completed.

💡 Why?

This restriction exists as a safety mechanism — imagine execute() (which runs once PER CHUNK, potentially hundreds of times for a large dataset) were allowed to freely start new batch jobs; a single misconfigured batch could spawn hundreds of additional batch jobs uncontrollably, exhausting org-wide async capacity in minutes. Restricting new-batch-starts to finish() (which runs exactly ONCE regardless of how many chunks were processed) caps the chaining to a predictable, linear sequence rather than an exponential explosion.

🌍 Real World Example

A developer at XYZ Company initially tried calling Database.executeBatch() inside execute() to kick off a follow-up batch per chunk — with 5,000 records and a scope of 200, that would have attempted to start 25 separate new batch jobs, immediately throwing a runtime error since new batches can only launch from finish(). Restructuring to trigger the next batch from finish() (running once, after ALL chunks complete) fixed it cleanly.

🎤 One-Line Answer

"start()/execute() already run async — Salesforce blocks starting a new Batch from execute() to prevent runaway chaining. You can enqueue a Queueable from execute(), but a new Batch can only be started from finish()."

Q27

Can we call @future from another @future method? Can we call a Batch from another Batch?

✅ Direct Answer

@future cannot call another @future method — Salesforce blocks nested future calls entirely and throws a runtime error if attempted. Batch calling Batch: yes, this IS allowed (called "chaining"), but ONLY from the finish() method of the currently completing batch — you cannot start a new batch from the start() or execute() method of the currently running batch (see Q26).

💡 Why?

@future's restriction is stricter than Batch's because @future has no equivalent to Batch's finish() lifecycle hook — there's no "safe point" in a @future method's execution where Salesforce can guarantee a nested call won't create an uncontrolled chain, so it's blocked outright. Batch Apex was specifically designed with finish() as that safe chaining point, which is why Salesforce allows Batch-to-Batch chaining but not @future-to-@future nesting.

🌍 Real World Example

XYZ Company migrated a multi-step data sync process that originally attempted @future methods calling other @future methods (which failed at runtime) into a Queueable chain instead — Queueable supports self-chaining from within its own execute() method (up to a limited depth in production), which @future simply cannot do.

🎤 One-Line Answer

"No — @future methods cannot call other @future methods, that's blocked outright. Batch chaining IS allowed, but only by calling Database.executeBatch() from the finish() method, never from start() or execute()."

Q28

Can we make an HTTP callout from Batch Apex?

✅ Direct Answer

Yes — implement the Database.AllowsCallouts marker interface alongside Database.Batchable on the batch class. Without explicitly declaring this interface, any HTTP callout attempted inside execute() throws a CalloutException, because Salesforce requires you to explicitly opt in to network access from within an async job for security/governance reasons.

💡 Why?

Requiring the explicit AllowsCallouts declaration forces developers to make a conscious decision about network access rather than accidentally allowing it — this matters in enterprise governance because callouts from batch jobs processing large volumes of records can create significant external system load (imagine 100,000 records each triggering an API call), so making it opt-in encourages developers to think about rate limiting and scope size before enabling it.

🌍 Real World Example

global class SyncBatch implements Database.Batchable<SObject>, Database.AllowsCallouts { global Database.QueryLocator start(Database.BatchableContext bc) { return Database.getQueryLocator('SELECT Id FROM Account WHERE Synced__c = false'); } global void execute(Database.BatchableContext bc, List<Account> scope) { Http h = new Http(); HttpRequest req = new HttpRequest(); req.setEndpoint('callout:ERP_System/sync'); req.setMethod('POST'); h.send(req); // Allowed because of Database.AllowsCallouts } global void finish(Database.BatchableContext bc) {} }

XYZ Company's ERP sync batch initially forgot the AllowsCallouts interface — it worked fine in dev testing with a small dataset until it was run against a real batch of 50,000 unsynced Accounts, immediately throwing CalloutException on the first execute() chunk. Adding the interface, and additionally reducing the batch scope size to 50 records per chunk to respect the ERP's rate limits, resolved it.

🎤 One-Line Answer

"Yes — implement Database.AllowsCallouts alongside Database.Batchable. Without that marker interface, any HTTP callout in execute() throws a CalloutException."

Q29

How do you run two unrelated queries in a single Batch class?

✅ Direct Answer

Database.getQueryLocator() in start() supports only ONE query. For two genuinely unrelated queries, your realistic options are: 1) run two completely separate Batch classes if the datasets don't need to be processed together, 2) combine them into a single query if the objects share any relationship (even indirectly), or 3) query the second unrelated dataset fresh inside execute() for each chunk of the first — accepting the extra SOQL cost per chunk since execute() gets fresh governor limits each time.

💡 Why?

This question exposes a real architectural constraint of the Batchable interface — start() is designed around a single QueryLocator/Iterable as the batch's driving dataset, because that's what determines the chunking and pagination behavior. Trying to force two unrelated datasets into one batch job usually signals a design smell — if the two datasets genuinely have nothing to do with each other, they probably belong in two separate scheduled batch jobs rather than artificially coupled into one.

🌍 Real World Example

XYZ Company needed to nightly process both stale Leads AND expired Contracts — two entirely unrelated objects with no shared relationship. Rather than forcing them into one awkward batch, they simply scheduled two separate Batch classes (LeadCleanupBatch and ContractExpiryBatch) at the same 2 AM window — cleaner code, easier to monitor independently in the Apex Jobs list, and each can be re-run or paused without affecting the other.

🎤 One-Line Answer

"start() only supports one QueryLocator — for a genuinely unrelated second dataset, either split into two separate Batch classes, or query the second dataset fresh inside execute() for each chunk of the first."

Q30

Write the basic syntax structure of Batch Apex.

✅ Direct Answer

Implement the Database.Batchable<SObject> interface with three required methods: start() returns a QueryLocator (or Iterable) defining the full scope, execute() runs once per chunk (default 200 records, configurable), and finish() runs exactly once after all chunks have completed, typically used for post-processing or chaining the next job.

🌍 Real World Example

global class MyBatchClass implements Database.Batchable<SObject> { global Database.QueryLocator start(Database.BatchableContext bc) { return Database.getQueryLocator('SELECT Id, Name FROM Account WHERE Rating = null'); } global void execute(Database.BatchableContext bc, List<SObject> scope) { List<Account> toUpdate = new List<Account>(); for(SObject s : scope) { Account a = (Account)s; a.Rating = 'Cold'; toUpdate.add(a); } update toUpdate; } global void finish(Database.BatchableContext bc) { // Post-processing: send email, chain next batch, etc. } } // Execute: Database.executeBatch(new MyBatchClass(), 200);

🎤 One-Line Answer

"Implement Database.Batchable — start() returns a QueryLocator defining scope, execute() processes each chunk (default 200), finish() runs once after all chunks complete for post-processing or chaining."

Q31

SCENARIO: A Data Loader job updates 100 Opportunities to Stage = Closed 1 month ago. Now the customer wants to undo those changes. How do you approach this?

✅ Direct Answer

The Recycle Bin won't help here (that's only for deleted records, not field updates, and only lasts 15 days anyway — the change was made a month ago). Real options: 1) If Field History Tracking was enabled on StageName BEFORE the original update, query the OpportunityHistory object to find the pre-change value per record, then Data Loader update them back to those original values. 2) If a backup/export was taken before the original update, restore from that export via Data Loader. 3) If neither exists, there is no reliable way to auto-recover the exact prior values — you would need business input on what the correct values should be for each of the 100 records.

💡 Why?

This is one of the most important scenario questions because it tests whether you understand that Salesforce has NO built-in "undo" for DML updates — unlike a document editor's Ctrl+Z, once a field update commits, the prior value is gone unless you specifically had a safety net in place beforehand. The only real safety nets are Field History Tracking (if proactively enabled before the change), a pre-change export/backup, or a 3rd-party backup tool like OwnBackup or Odaseva that offers point-in-time restore. This is exactly why the real "correct" answer to this scenario always includes the forward-looking lesson: always export a backup CSV before any mass Data Loader update.

🌍 Real World Example

SELECT Field, OldValue, NewValue, CreatedDate FROM OpportunityFieldHistory WHERE OpportunityId IN :affectedOppIds AND Field = 'StageName' ORDER BY CreatedDate DESC

XYZ Company faced this exact situation — a bulk Stage update needed reverting after the customer changed their mind about a process change a month later. Because Field History Tracking had been enabled on StageName for over a year, they queried OpportunityFieldHistory for the OldValue per record right before the mass update's timestamp, exported that as a CSV, and re-ran Data Loader to restore each Opportunity to its correct pre-change Stage — a recovery that would have been completely impossible without history tracking already switched on.

🔑 Key Points for Interviewer

Recycle Bin ≠ field-level undo — only helps with deletes, and only for 15 days
Field History Tracking (if enabled beforehand): OpportunityHistory object stores OldValue/NewValue per field change
Best practice: ALWAYS export current data before any mass Data Loader update — this is the real lesson interviewers want to hear
3rd-party backup tools (OwnBackup, Odaseva) provide point-in-time restore for exactly this scenario

🎤 One-Line Answer

"There's no native undo — check if Field History Tracking was enabled on StageName (query OpportunityHistory for prior values) or restore from a pre-update backup export. The real lesson: always export a backup CSV before any mass Data Loader update."

💻 Section 4 — LWC Fundamentals

Q32–Q42 · Asked in Every Round

Q32

Explain LWC lifecycle hooks with practical use cases.

✅ Direct Answer

constructor() — fires once, before any DOM or parent property access, rarely used beyond calling super(). connectedCallback() — fires once when the component is inserted into the DOM, ideal for data loading and subscriptions. renderedCallback() — fires after EVERY render (initial AND every subsequent re-render), so it MUST be guarded with a boolean flag to avoid repeating logic. disconnectedCallback() — fires once on removal from DOM, used for cleanup (unsubscribing, clearInterval). errorCallback() — catches errors thrown by descendant/child components.

💡 Why?

renderedCallback is the single most common source of LWC bugs candidates need to understand deeply — because it fires on EVERY re-render (triggered by any reactive property change), code that initializes a chart library or a DOM element without a guard will re-initialize on every single click, keystroke, or data update, sometimes causing duplicate event listeners, memory leaks, or visibly broken UI (like a chart re-rendering from scratch and flickering). The isInitialized boolean pattern exists specifically to make renderedCallback behave like a "run once" hook when that's what you actually need.

🌍 Real World Example

renderedCallback() { if(this.isInitialized) return; this.isInitialized = true; const canvas = this.template.querySelector('canvas'); if(canvas) this.initializeChart(canvas); }

An LWC dashboard component at XYZ Company initialized a Chart.js graph inside renderedCallback WITHOUT a guard — every time a filter dropdown changed (triggering a reactive re-render), the chart re-initialized from scratch, causing a visible flicker and, worse, leaking a new Chart.js instance into memory each time without disposing the old one, eventually crashing the browser tab after extended use. Adding the isInitialized guard fixed both issues.

🎤 One-Line Answer

"constructor (once, no DOM) → connectedCallback (once, load data here) → renderedCallback (every render, guard with a boolean) → disconnectedCallback (once, cleanup here) — renderedCallback firing repeatedly is the #1 gotcha."

Q33

What are Decorators in LWC? Explain @api, @track, @wire.

✅ Direct Answer

Decorators add special behavior to class properties/methods. @api: marks a property/method public — the parent component can set it via an attribute, or an external caller (like a Flow) can invoke it. @track: makes an object/array reactive to internal (deep) mutations — rarely needed in modern LWC since primitives are auto-reactive by default; @track is only required when you mutate nested properties of an object or array in place. @wire: binds a property or function to an Apex method or Lightning Data Service wire adapter, and re-fires reactively whenever any reactive ($) parameter changes.

💡 Why?

A common misconception is applying @track everywhere "just in case" — but LWC's rendering engine is already reactive by default for any property reassignment (this.myArray = [...this.myArray, newItem]), and @track only matters for the narrower case of mutating an existing object/array's internal properties WITHOUT reassigning the whole reference (this.myObject.name = 'new'). Understanding this distinction avoids both unnecessary boilerplate and, more importantly, subtle bugs where a developer mutates a nested property expecting reactivity that doesn't actually fire without @track.

🌍 Real World Example

A developer at XYZ Company had a component where updating a nested field inside a wrapper object (this.formData.email = newEmail) silently didn't refresh the UI — because reassigning a nested property doesn't trigger reactivity on a plain @api or default property. Adding @track this.formData fixed it, though the team eventually preferred reassigning the whole object (this.formData = {...this.formData, email: newEmail}) since that pattern works without needing @track at all and is considered the more modern approach.

🎤 One-Line Answer

"@api exposes a property/method publicly to the parent. @track makes deep object mutations reactive (rarely needed now). @wire declaratively binds Apex/LDS data, auto-refiring when reactive ($) parameters change."

Q34

What is the difference between @wire and an imperative Apex call? Show the syntax for both.

✅ Direct Answer

@wire: declarative, auto-calls the Apex method the instant the component loads and again automatically whenever any reactive ($) parameter changes, best for reads, and only works with @AuraEnabled(cacheable=true) methods. Imperative: Promise-based, called explicitly (e.g., on button click via await), required for any DML/write operation since @wire structurally only supports cacheable (read-only) Apex methods.

💡 Why?

This restriction — @wire only works with cacheable=true — isn't arbitrary; it exists because @wire's whole value proposition is client-side caching and automatic re-fetching, both of which require the underlying operation to be side-effect-free and repeatable. A method that performs DML can't safely be "silently re-called" whenever a reactive parameter changes, since that could trigger unintended duplicate writes — so Salesforce enforces the cacheable requirement at the platform level, refusing to even compile a @wire pointing at a non-cacheable method.

🌍 Real World Example

// @WIRE - declarative, auto-loads import { wire } from 'lwc'; import getAccounts from '@salesforce/apex/AccountController.getAccounts'; @wire(getAccounts, { industry: '$selectedIndustry' }) wiredAccounts({ data, error }) { if(data) this.accounts = data; if(error) this.errorMsg = error.body.message; } // IMPERATIVE - called on demand import saveAccount from '@salesforce/apex/AccountController.saveAccount'; async handleSave() { try { await saveAccount({ accData: this.formData }); } catch(error) { this.errorMsg = error.body.message; } }

XYZ Company's Account list component uses @wire with a reactive industry filter parameter — every time the user changes a dropdown, the wire automatically re-fires and refreshes the list with zero manual refresh logic needed. Saving edits, however, goes through an imperative call, since @wire simply cannot be used for the DML-performing saveAccount method.

🎤 One-Line Answer

"@wire auto-loads reactively and only works with cacheable=true methods — use for reads. Imperative calls (await someMethod()) are on-demand and required for DML/writes."

Q35

What is Lightning Data Service (LDS) and why is it important?

✅ Direct Answer

LDS provides zero-Apex CRUD via lightning-record-form / lightning-record-edit-form / getRecord+updateRecord wire adapters. Importance: it automatically enforces FLS and validation rules with no extra code, it shares one client-side cache across EVERY LDS-based component on the page (edit an Account in one component, every other component showing that same Account auto-refreshes to reflect it), and it eliminates the boilerplate Apex controller + test class code that a simple CRUD screen would otherwise require.

💡 Why?

The shared cache behavior is genuinely important and frequently misunderstood — because multiple independent LDS components on the same page read from the SAME underlying record cache, updating a record in one component causes every OTHER component displaying that record to automatically re-render with the new value, with zero manual event-passing or refreshApex calls required. This "just works" synchronization is a major reason to prefer LDS over custom Apex whenever the requirement is genuinely simple single-record CRUD.

🌍 Real World Example

XYZ Company built an Account detail page with three separate LWC components: a header showing the Account Name, an inline edit form, and a related-info panel. All three use LDS's getRecord/updateRecord for the same Account — when a user edits the Name via the inline form, the header component automatically updates too, without any custom event wiring, purely because both components are reading from the same LDS cache.

🎤 One-Line Answer

"LDS gives zero-Apex CRUD that respects FLS/validation rules automatically and shares one client-side cache across every component on the page — use it for standard record CRUD instead of writing custom Apex."

Q36

How do you display data from a @wire method into a lightning-datatable?

✅ Direct Answer

Wire the Apex method's result directly into a property, define a columns array describing each column's label/fieldName/type, and bind both data and columns to the lightning-datatable component along with a required key-field (typically Id) that lets the framework efficiently track and diff rows.

🌍 Real World Example

// JS import { LightningElement, wire } from 'lwc'; import getAccounts from '@salesforce/apex/AccountController.getAccounts'; export default class AccountTable extends LightningElement { accounts; error; columns = [ { label: 'Name', fieldName: 'Name' }, { label: 'Rating', fieldName: 'Rating' }, { label: 'Phone', fieldName: 'Phone', type: 'phone' } ]; @wire(getAccounts) wiredAccounts({ data, error }) { if(data) this.accounts = data; if(error) this.error = error; } } // HTML // <lightning-datatable key-field="Id" data={accounts} columns={columns} hide-checkbox-column> // </lightning-datatable>

XYZ Company's Opportunity dashboard uses this exact pattern — one @wire call populates the datatable, and because the wire is reactive to a search-term parameter, typing in a search box automatically re-fires the wire and refreshes the table with zero manual data-fetching logic.

🎤 One-Line Answer

"@wire the Apex method into a property, define a columns array with label/fieldName/type, then bind data={accounts} and columns={columns} on lightning-datatable with key-field='Id'."

Q37

Write JavaScript code to show Account fields Name, Rating, and Phone.

✅ Direct Answer

Import field references from @salesforce/schema, wire them into getRecord, and expose each field's value via a getter using getFieldValue() — this pattern gives compile-time validation of field/object API names, unlike a hardcoded string approach.

🌍 Real World Example

import { LightningElement, api, wire } from 'lwc'; import { getRecord, getFieldValue } from 'lightning/uiRecordApi'; import NAME_FIELD from '@salesforce/schema/Account.Name'; import RATING_FIELD from '@salesforce/schema/Account.Rating'; import PHONE_FIELD from '@salesforce/schema/Account.Phone'; export default class AccountFields extends LightningElement { @api recordId; @wire(getRecord, { recordId: '$recordId', fields: [NAME_FIELD, RATING_FIELD, PHONE_FIELD] }) account; get name() { return getFieldValue(this.account.data, NAME_FIELD); } get rating() { return getFieldValue(this.account.data, RATING_FIELD); } get phone() { return getFieldValue(this.account.data, PHONE_FIELD); } }

🎤 One-Line Answer

"Use getRecord wire adapter with @salesforce/schema field imports for Name/Rating/Phone, then getFieldValue() getters to safely extract each value from the wire result."

Q38

How do you restrict users from copy-pasting text into a text box in LWC — they should only be able to type?

✅ Direct Answer

Attach an onpaste (and typically oncopy/oncut) event handler on the lightning-input and call event.preventDefault() to block the paste action from taking effect.

💡 Why?

It's important to flag the limitation honestly in an interview: this is a UX-level deterrent only, not a genuine security or data-integrity control — a technically capable user can bypass it via browser DevTools, disabling JavaScript, or using browser automation tools to inject text directly. If the actual requirement is preventing certain content patterns (not just the paste ACTION), the correct approach is server-side validation (a Validation Rule or Apex check on save), because client-side JavaScript restrictions can never be trusted as a real security boundary.

🌍 Real World Example

// HTML // <lightning-input label="Enter Code" onpaste={handlePaste}></lightning-input> // JS handlePaste(event) { event.preventDefault(); // Optionally show a toast: "Pasting is not allowed here" }

XYZ Company's compliance team requested a "no paste" field for a verification code entry screen, intending to force users to genuinely type it rather than copy from elsewhere. The onpaste handler satisfied that specific UX requirement, but the team explicitly documented that it's not a hard security control — the actual verification logic still validates the code server-side in Apex regardless of how it was entered.

🎤 One-Line Answer

"Bind an onpaste handler and call event.preventDefault() — but flag to the interviewer that this is a UX-level deterrent only, not a real security or data-integrity control."

Q39

What is a Toast Message in LWC? How many types are there?

✅ Direct Answer

A Toast is a brief pop-up notification shown via ShowToastEvent (from lightning/platformShowToastEvent). Four variant types: info (default, blue), success (green), warning (yellow), error (red). It also supports a mode attribute: 'dismissible' (default, auto-closes after a few seconds), 'sticky' (stays visible until the user manually closes it — reserved for important errors), and 'pester' (repeats to draw attention).

💡 Why?

Choosing the right variant AND mode combination is a real UX decision, not just a technicality — using 'sticky' mode for routine success confirmations is annoying (users have to manually dismiss something they already expected), while using the default dismissible mode for a critical save-failure error means the user might miss it entirely if they look away for a moment. The convention most mature Salesforce teams follow is: success/info use dismissible, error uses sticky.

🌍 Real World Example

import { ShowToastEvent } from 'lightning/platformShowToastEvent'; this.dispatchEvent(new ShowToastEvent({ title: 'Success', message: 'Record saved successfully', variant: 'success', mode: 'dismissible' }));

XYZ Company standardized their toast usage across all LWC components: success/info toasts auto-dismiss after 5 seconds (mode: dismissible), while error toasts always use mode: sticky so a failed save is never accidentally missed by a busy user who's already moved their attention elsewhere.

🎤 One-Line Answer

"Four toast variants: info, success, warning, error — dispatched via ShowToastEvent from lightning/platformShowToastEvent, with mode 'sticky' for errors that shouldn't auto-dismiss."

Q40

What is uiRecordApi and why do we use it?

✅ Direct Answer

lightning/uiRecordApi is the module powering Lightning Data Service — it exposes getRecord, createRecord, updateRecord, deleteRecord, and getFieldValue functions for zero-Apex CRUD directly from LWC JavaScript. It's used because it auto-enforces FLS/validation rules with no extra code, and it shares its cache with every other LDS-based component on the page, reducing both the amount of Apex code you write AND the number of duplicate server round-trips.

🎤 One-Line Answer

"lightning/uiRecordApi provides getRecord/createRecord/updateRecord/deleteRecord for zero-Apex CRUD via LDS — used because it auto-enforces FLS/validation and shares a page-wide cache, avoiding redundant Apex and server calls."

Q41

What are the different ways to get data from the backend in LWC?

✅ Direct Answer

1) @wire to an Apex method (declarative, cacheable). 2) Imperative Apex call (on-demand, Promise-based). 3) Lightning Data Service (getRecord wire adapter — zero Apex). 4) @wire to a UI API module directly (getObjectInfo, getPicklistValues). 5) An Apex controller wrapping a REST callout to an external system. 6) The newer GraphQL wire adapter, for fetching complex nested data in a single round trip.

💡 Why?

Interviewers want to see that you can choose the RIGHT one for the situation, not just list them — LDS is fastest to build for simple single-record CRUD, @wire-to-Apex is the go-to for anything more complex needing custom SOQL logic, and GraphQL specifically shines when a single component needs deeply nested related data (e.g., Account + its Contacts + each Contact's Opportunities) in one efficient call instead of multiple round trips.

🎤 One-Line Answer

"Six ways: @wire to Apex, imperative Apex calls, Lightning Data Service (getRecord), UI API wire modules (getObjectInfo/getPicklistValues), Apex-wrapped REST callouts, and the newer GraphQL wire adapter."

Q42

Explain child-to-parent communication in Aura Components.

✅ Direct Answer

Aura uses a Component Event (aura:event type="COMPONENT") — the child registers and fires it, and the parent registers a handler for it by explicitly declaring the event name as an attribute on the child's tag in markup. Unlike LWC's CustomEvent (which bubbles up the DOM automatically), Aura Component Events require this explicit parent-side wiring at the point where the child is used.

💡 Why?

This is often asked specifically because most candidates only know LWC patterns and need to demonstrate they can also work on legacy Aura codebases still common at Capgemini and other consulting firms with long-tenured client orgs — knowing this pattern signals you can maintain existing Aura components without needing an immediate LWC rewrite for every bug fix, which is important for realistic project timelines.

🌍 Real World Example

<aura:component> <aura:registerEvent name="itemSelected" type="c:ItemSelectedEvent"/> <lightning:button label="Select" onclick="{!c.handleClick}"/> </aura:component> // Child controller.js handleClick: function(component, event, helper) { var selectedEvent = component.getEvent("itemSelected"); selectedEvent.setParams({ "itemId": "123" }); selectedEvent.fire(); }  <c:childComponent itemSelected="{!c.handleItemSelected}"/>

XYZ Company maintains a legacy Aura-based Community page predating their LWC migration — a child item-selector component fires a Component Event on selection, and the parent page's controller.js handles it via the itemSelected attribute declared on the child's tag, exactly mirroring how the equivalent LWC CustomEvent pattern works today.

🎤 One-Line Answer

"Aura child-to-parent uses a Component Event — child fires it via registerEvent/fire(), parent explicitly declares a handler attribute on the child's tag in markup, unlike LWC's auto-bubbling CustomEvent."

🔀 Section 5 — LWC Communication & Navigation

Q43–Q49 · Live Coding Common

Q43

Write LWC child-to-parent communication code.

✅ Direct Answer

The child creates and dispatches a CustomEvent carrying a detail payload; the parent listens for it by adding an on+eventname attribute directly on the child's tag in its own template, then reads event.detail in the handler to get the data the child sent.

🌍 Real World Example

// CHILD component (childComp.js) export default class ChildComp extends LightningElement { handleClick() { this.dispatchEvent(new CustomEvent('itemselect', { detail: { itemId: '001', itemName: 'Widget' } })); } } // PARENT markup // <c-child-comp onitemselect={handleItemSelect}></c-child-comp> // PARENT JS handleItemSelect(event) { const { itemId, itemName } = event.detail; console.log('Selected: ' + itemName + ' (' + itemId + ')'); }

🎤 One-Line Answer

"Child dispatches a CustomEvent with a detail payload — parent listens via on+eventname on the child's tag (onitemselect) and reads event.detail to get the data."

Q44

How do you pass a value from one component to another (unrelated) component in LWC?

✅ Direct Answer

For unrelated/sibling components with no parent-child relationship anywhere in the DOM tree, use Lightning Message Service (LMS) — publish a message on a shared Message Channel from one component, subscribe to it in the other, regardless of where each one sits on the page or how deeply nested it is.

💡 Why?

This distinction matters because the @api/CustomEvent pattern only works along a direct parent-child DOM relationship — if two components are siblings placed independently on a Lightning App Page or Record Page with no shared ancestor that mediates between them, there's structurally no way for a CustomEvent to bubble from one to the other. LMS was specifically built to solve exactly this gap, working even across completely different component types (LWC, Aura, Visualforce) on the same page.

🎤 One-Line Answer

"For unrelated components: Lightning Message Service — publish() on a Message Channel from one component, subscribe() in the other. For parent-child: @api property (down) and CustomEvent (up)."

Q45

How do you create a channel in the pub-sub model — create channel, subscribe, and publish?

✅ Direct Answer

1) Create Channel: add a Lightning Message Channel metadata file (force-app/main/default/messageChannels/MyChannel.messageChannel-meta.xml) defining the channel's name and its message payload fields. 2) Publish: import publish + MessageContext from lightning/messageService, call publish(context, MY_CHANNEL, payload) from the sending component. 3) Subscribe: import subscribe + MessageContext, call subscribe(context, MY_CHANNEL, callback) in connectedCallback of the receiving component, and always unsubscribe() in disconnectedCallback to prevent memory leaks.

💡 Why?

The unsubscribe-in-disconnectedCallback step is not optional housekeeping — it's a genuine bug source if skipped. If a component subscribes but is later removed from the DOM (e.g., a modal that closes, or navigation to a different record) without unsubscribing, the subscription callback remains registered and can fire on stale, already-removed component state, or accumulate multiple duplicate subscriptions if the component is re-mounted repeatedly — both cause real, hard-to-diagnose bugs in production.

🌍 Real World Example

<LightningMessageChannel xmlns="http://soap.sforce.com/2006/04/metadata"> <masterLabel>RecordSelected</masterLabel> <isExposed>true</isExposed> <lightningMessageFields> <fieldName>recordId</fieldName> </lightningMessageFields> </LightningMessageChannel> // 2. PUBLISH (componentA.js) import { publish, MessageContext } from 'lightning/messageService'; import RECORD_SELECTED from '@salesforce/messageChannel/RecordSelected__c'; @wire(MessageContext) messageContext; handleSelect(id) { publish(this.messageContext, RECORD_SELECTED, { recordId: id }); } // 3. SUBSCRIBE (componentB.js) import { subscribe, unsubscribe, MessageContext } from 'lightning/messageService'; import RECORD_SELECTED from '@salesforce/messageChannel/RecordSelected__c'; @wire(MessageContext) messageContext; subscription = null; connectedCallback() { this.subscription = subscribe(this.messageContext, RECORD_SELECTED, (msg) => { this.loadRecord(msg.recordId); }); } disconnectedCallback() { unsubscribe(this.subscription); }

XYZ Company built a warehouse dashboard where a list component and a detail-panel component sit independently on the same App Page (no parent-child relationship). Selecting a row in the list publishes a RecordSelected message; the detail panel subscribes and updates instantly — and because the detail panel properly unsubscribes in disconnectedCallback, navigating away and back doesn't leave orphaned subscriptions accumulating.

🎤 One-Line Answer

"Create a Message Channel metadata file, publish() from the sender with the channel + payload, subscribe() in connectedCallback on the receiver, and always unsubscribe() in disconnectedCallback to prevent memory leaks."

Q46

How do you navigate to another record page on click of a button in LWC?

✅ Direct Answer

Extend the component with NavigationMixin, then call this[NavigationMixin.Navigate]() with a standard__recordPage page reference object containing the recordId, objectApiName, and actionName.

🌍 Real World Example

import { LightningElement, api } from 'lwc'; import { NavigationMixin } from 'lightning/navigation'; export default class OpenRecord extends NavigationMixin(LightningElement) { @api recordId; handleClick() { this[NavigationMixin.Navigate]({ type: 'standard__recordPage', attributes: { recordId: this.recordId, objectApiName: 'Account', actionName: 'view' } }); } }

🎤 One-Line Answer

"Extend NavigationMixin(LightningElement), then call this[NavigationMixin.Navigate]({type:'standard__recordPage', attributes:{recordId, objectApiName, actionName:'view'}})."

Q47

What are Navigation Services in LWC?

✅ Direct Answer

NavigationMixin (from lightning/navigation) provides programmatic navigation to standard pages (records, object lists, tabs, named pages), web pages, and Knowledge articles — and it works consistently across Lightning Experience, the Salesforce Mobile App, and Experience Cloud without any environment-specific code. Two main methods: Navigate() (perform the actual navigation) and GenerateUrl() (get the destination URL as a plain string, e.g., for use in an href attribute, without triggering navigation).

🎤 One-Line Answer

"NavigationMixin exposes Navigate() (go to a page reference) and GenerateUrl() (get URL as a string without navigating) — works consistently across Lightning Experience, Mobile, and Experience Cloud."

Q48

How do you make a callout from LWC (i.e., call an external/third-party service from an LWC)?

✅ Direct Answer

LWC JavaScript CANNOT make HTTP callouts directly to external systems — browser CORS/CSP restrictions and Salesforce's security policy block arbitrary fetch()/XMLHttpRequest calls from LWC to non-whitelisted external domains. The correct pattern: the LWC calls an imperative Apex method → that Apex method makes the HTTP callout server-side (via HttpRequest + Named Credential) → the result is returned back to the LWC as the resolved Promise value.

💡 Why?

This restriction is a genuine security boundary, not just a technical limitation — allowing arbitrary client-side JavaScript to make direct network calls from inside a Salesforce org would expose credentials and endpoint details to the browser and any user who inspects network traffic, and would completely bypass server-side governance (Named Credentials, callout limits, audit logging). Routing every external call through Apex keeps authentication server-side and gives you a single, auditable choke point for all outbound integrations.

🌍 Real World Example

// Apex - makes the actual callout public with sharing class WeatherService { @AuraEnabled public static String getWeather(String city) { HttpRequest req = new HttpRequest(); req.setEndpoint('callout:Weather_API/forecast?city=' + city); req.setMethod('GET'); HttpResponse res = new Http().send(req); return res.getBody(); } } // LWC - calls Apex, never the external API directly import getWeather from '@salesforce/apex/WeatherService.getWeather'; async handleFetch() { this.result = await getWeather({ city: 'Mumbai' }); }

A new developer at XYZ Company initially tried calling fetch() directly from an LWC's JavaScript to hit a third-party shipping-rate API — it failed immediately due to CSP restrictions in the Salesforce runtime. Wrapping the call in an Apex method using a Named Credential resolved it cleanly and, as a bonus, meant the API key never touched the browser at all.

🎤 One-Line Answer

"LWC can't call external services directly — it calls an imperative Apex method, and that Apex method makes the actual HTTP callout via Named Credential, then returns the result back to the component."

Q49

SCENARIO: An Opportunity's Stage is published via a Platform Event and must be caught by a third-party system, and also shown live in an LWC component. Walk through the design.

✅ Direct Answer

1) Create a Platform Event (Stage_Change__e) with fields for OpportunityId and NewStage. 2) After-update trigger on Opportunity: when StageName actually changes, publish the event via EventBus.publish(). 3) The 3rd-party system subscribes independently via CometD/Streaming API directly to the event channel — it has no dependency on Salesforce's internal UI at all. 4) The LWC subscribes to the SAME Platform Event using the empApi module (imported from lightning/empApi), updating its own local state and re-rendering live in the callback.

💡 Why?

This scenario is specifically designed to test your understanding of the publish-subscribe decoupling principle — the trigger that publishes the event has ZERO knowledge of who's listening, whether it's the third-party system, the LWC, both, or neither. This is architecturally superior to the trigger directly calling out to the third party AND separately pushing an update to the UI, because adding a THIRD subscriber later (say, a Slack notification) requires zero changes to the original trigger — you just add another independent subscriber to the same event.

🌍 Real World Example

// Trigger - publish on stage change trigger OpportunityTrigger on Opportunity (after update) { List<Stage_Change__e> events = new List<Stage_Change__e>(); for(Opportunity opp : Trigger.new) { if(opp.StageName != Trigger.oldMap.get(opp.Id).StageName) { events.add(new Stage_Change__e( OpportunityId__c = opp.Id, NewStage__c = opp.StageName )); } } if(!events.isEmpty()) EventBus.publish(events); } // LWC - subscribe using empApi import { subscribe, unsubscribe } from 'lightning/empApi'; connectedCallback() { subscribe('/event/Stage_Change__e', -1, (msg) => { this.currentStage = msg.data.payload.NewStage__c; }).then(response => { this.subscription = response; }); }

XYZ Company's warehouse fulfillment system needed real-time notification the instant a deal closed, and their internal sales dashboard needed a live-updating "just closed" ticker. Both were built as independent subscribers to the same Stage_Change__e event — when the warehouse system was later replaced with a different vendor, the trigger and the LWC dashboard needed zero changes; only the external subscriber's connection details changed.

🔑 Key Points for Interviewer

Platform Event decouples publisher from subscribers — trigger doesn't know or care who's listening
3rd-party system uses CometD/Streaming API to subscribe externally
LWC uses lightning/empApi module (built on the same underlying Streaming API)
Both subscribers receive the event independently and in real time, with no coordination needed between them

🎤 One-Line Answer

"Publish a custom Platform Event from an after-update trigger on stage change — the 3rd-party system subscribes via CometD/Streaming API, and the LWC subscribes to the same event using the lightning/empApi module — both react independently in real time."

🔄 Section 6 — Flows & Automation

Q50–Q54

Q50

Explain Flow Screen elements.

✅ Direct Answer

Screen elements are the UI building blocks in a Screen Flow: standard input components (Text, Number, Date, Picklist, Checkbox, Currency), Display Text (static/formatted read-only text), Section (multi-column layout grouping for organizing fields visually), Data Table (display and let users select records), Address/Name compound components, and custom Lightning Web Components exposed as Screen Flow components via the lightning__FlowScreen target.

💡 Why?

The ability to expose a custom LWC as a Screen Flow component is the single most powerful escape hatch in Flow — it means whenever the standard Screen elements can't deliver a specific UX (search-as-you-type, drag-and-drop, a rich data visualization), you don't have to abandon Flow entirely for a full custom Visualforce/Aura app. You build ONE LWC targeting lightning__FlowScreen, and it slots into the Flow's guided journey as if it were a native element, giving admins the ability to keep the surrounding process declarative while the one complex screen gets custom code.

🌍 Real World Example

XYZ Company's returns process runs as a Screen Flow so the support lead can freely edit the questions and branching logic without needing a developer — but one specific screen (the product picker) needed search-as-you-type with image thumbnails, which standard Screen elements structurally can't deliver. They built one custom LWC targeting lightning__FlowScreen just for that screen, keeping every other step of the process fully declarative.

🎤 One-Line Answer

"Screen elements are the Flow's UI building blocks — Text/Number/Picklist/Checkbox inputs, Display Text, Section (layout), Data Table, and custom LWCs exposed via the lightning__FlowScreen target."

🔗 Section 7 — Integration & Named Credentials

Q55–Q61 · Cross-Topic Focus

Q55

What is a Named Credential?

✅ Direct Answer

A Named Credential stores an external endpoint URL plus its authentication details (OAuth tokens, API keys, certificates) securely in Salesforce metadata — encrypted and never exposed in code. Apex callouts reference it as 'callout:CredentialName' instead of hardcoding the URL and credentials directly in the source. Salesforce auto-handles OAuth token refresh behind the scenes, and using a Named Credential means you don't need a separate Remote Site Setting for that same domain.

💡 Why?

The security implication is the real reason this matters beyond convenience — hardcoded credentials in Apex source code end up committed to version control (Git), visible to every developer with repo access, and nearly impossible to rotate cleanly (you'd need a code deployment just to change an API key). Named Credentials solve all three problems at once: the secret never touches source code, access is controlled through Setup permissions rather than repo access, and rotating a credential is a metadata change, not a deployment.

🌍 Real World Example

// WITHOUT Named Credentials - SECURITY RISK HttpRequest req = new HttpRequest(); req.setEndpoint('https://api.erp.com/orders'); req.setHeader('Authorization', 'Bearer hardcoded_token_here'); // In GitHub = security breach! // WITH Named Credentials - SECURE HttpRequest req = new HttpRequest(); req.setEndpoint('callout:ERP_Integration/orders'); req.setMethod('GET');

A security audit at XYZ Company found a hardcoded API token committed to their Git repository from an early integration prototype — the token had been sitting there, visible to every developer on the team, for over a year. Migrating to a Named Credential meant the token lived only in Salesforce's encrypted metadata store going forward, and rotating it after the incident required zero code changes.

🎤 One-Line Answer

"Named Credential stores the endpoint URL + auth details securely as metadata — referenced as 'callout:Name' in Apex, auto-refreshes OAuth tokens, and needs no separate Remote Site Setting."

🔍 Section 8 — SOQL & Reports

Q62–Q66

Q62

Write a SOQL query to fetch Accounts created yesterday.

✅ Direct Answer

Use the YESTERDAY date literal, which dynamically calculates the previous calendar day relative to the org's time zone at query execution time, so no hardcoded date math is ever needed.

🌍 Real World Example

SELECT Id, Name, CreatedDate FROM Account WHERE CreatedDate = YESTERDAY

XYZ Company's daily "new accounts created" summary email uses this exact query inside a Scheduled Apex job running at 7 AM every morning — because YESTERDAY dynamically resolves relative to today, the exact same query logic works correctly every single day without any code change.

🎤 One-Line Answer

"SELECT Id, Name FROM Account WHERE CreatedDate = YESTERDAY — a dynamic date literal, no hardcoded date math needed."

🎯 Section 9 — Scenario-Based & Miscellaneous

Q67–Q75 · Real Capgemini Interview Scenarios

Q67

What is the difference between a Custom Setting and a Custom Metadata Type?

✅ Direct Answer

Custom Metadata Type (__mdt): deploys WITH code/packages automatically, cached by the platform (no SOQL limit cost), usable directly in formulas, but does NOT support per-user/per-profile hierarchy overrides. Custom Setting (__c): does NOT deploy automatically with metadata (needs a separate data load per org/sandbox), counts against the SOQL limit unless it's specifically a List Custom Setting (which IS fully cached), but DOES support the Hierarchy type for genuine per-profile or per-user configuration overrides.

💡 Why?

The deployment behavior difference is the practical deciding factor in most real projects — Custom Metadata deploying automatically with a package means your integration endpoints, feature flags, and mapping tables travel seamlessly through your CI/CD pipeline into every sandbox and production with zero manual post-deployment steps. Custom Settings requiring a separate data load per environment is a genuine operational burden that teams frequently forget, leading to "works in sandbox, broken in production because nobody loaded the data" incidents — which is exactly why Salesforce's current guidance defaults to Custom Metadata unless you specifically need Hierarchy-type per-user overrides.

🌍 Real World Example

XYZ Company originally stored API endpoint URLs in Custom Settings — every sandbox refresh wiped that data, requiring a manual re-entry step that was regularly forgotten, causing integration failures that took hours to diagnose (the code was fine; the config data was just missing). Migrating to Custom Metadata Types meant the endpoints now deploy automatically with every package, eliminating that entire class of post-refresh incident permanently.

🎤 One-Line Answer

"Custom Metadata deploys with code and is always cache-free of SOQL limits — use for config that must travel between environments. Custom Settings support Hierarchy (per-user/profile) overrides but need separate data loads per org."

Q68

Have you worked on Salesforce Integration? What patterns have you used?

✅ Direct Answer

Frame your answer around real patterns you've actually implemented: REST callouts via Named Credentials for outbound sync to external systems, Apex REST endpoints (@RestResource) for inbound calls FROM external systems into Salesforce, Platform Events for decoupled asynchronous notifications between systems, and Batch Apex combined with Bulk API for scheduled high-volume data synchronization. Mention specific tools if genuinely used: MuleSoft as a middleware layer, Postman for callout testing during development, or a specific ERP/CRM system you've integrated with.

💡 Why?

Interviewers ask this open-endedly specifically to see whether you can articulate the REASONING behind pattern choice, not just recite a list — a strong answer naturally connects each pattern to WHY it was the right fit (e.g., "we used Platform Events instead of a direct synchronous callout because the external warehouse system's uptime wasn't guaranteed, and we didn't want a slow/down external system blocking our order-creation transaction").

🌍 Real World Example

At XYZ Company, I built the outbound sync from Salesforce Orders to their SAP ERP using Named Credential-based REST callouts triggered from a Queueable (to avoid the mixed-DML/callout-after-DML restriction), and separately built an inbound @RestResource endpoint that let their warehouse management system push shipment-status updates back into Salesforce, secured behind a Connected App with a scoped integration user.

🎤 One-Line Answer

"Yes — outbound REST callouts via Named Credentials, inbound @RestResource endpoints for external systems calling in, Platform Events for decoupled notifications, and Batch Apex/Bulk API for scheduled high-volume syncs."

Q69

Have you worked on Flows? What's your experience building them?

✅ Direct Answer

Frame your answer around specific flow types you've built: Record-Triggered Flows for automated field updates and related record creation, Screen Flows for guided data-entry wizards, Scheduled Flows for periodic cleanup or notification tasks, and calling Invocable Apex from Flow whenever a requirement exceeded what declarative logic alone could express. Mention your debugging approach too — Flow Builder's built-in Debug button for step-through testing, and always connecting Fault paths so failures are handled gracefully rather than silently.

💡 Why?

Mentioning Fault path connection specifically is a strong signal in this answer, because it distinguishes "I've clicked through Flow Builder a few times" from "I've built production-grade Flows" — an experienced Flow builder always treats error handling as non-negotiable, since an unconnected fault path means a Flow failure surfaces to the end user as a raw, confusing technical error message rather than a graceful, logged, and alerted failure.

🌍 Real World Example

At XYZ Company, I built a Record-Triggered Flow that creates related onboarding Tasks when an Opportunity closes — with a Fault path that logs the failure to a custom Flow_Error_Log__c object and sends an admin alert, so a downstream failure (like a validation rule blocking the Task creation) is caught and reported rather than silently failing or exposing a raw error to the sales rep.

🎤 One-Line Answer

"Yes — built Record-Triggered Flows for automation, Screen Flows for guided processes, Scheduled Flows for periodic jobs, and called Invocable Apex from Flow when requirements exceeded declarative logic, always with fault paths connected."

Q70

SCENARIO: Explain the Salesforce security model end-to-end, as you'd describe it in an interview.

✅ Direct Answer

There are two parallel, independent tracks that must BOTH be satisfied for a user to see and act on a record: Track 1 (Record-level): Organization-Wide Defaults (OWD, the restrictive baseline) → Role Hierarchy (managers inherit subordinates' access) → Sharing Rules, owner-based or criteria-based (extend access to groups/roles beyond OWD) → Manual Sharing (individual record grants by the owner). Track 2 (Object/Field-level): Profile — object CRUD + field-level security (FLS) + system permissions, exactly one mandatory per user → Permission Sets/Permission Set Groups — additional object/field/system access layered on top of the profile, purely additive.

💡 Why?

The single most important insight to communicate in this answer is that these two tracks are genuinely INDEPENDENT — a user could have full CRUD permission on the Opportunity object via their Profile (Track 2 satisfied) but still see zero Opportunity records if OWD is Private and no sharing mechanism grants them access (Track 1 not satisfied), or vice versa. Interviewers specifically listen for whether you present this as one unified system or correctly separate it into these two parallel, AND-gated tracks.

🎤 One-Line Answer

"Two parallel tracks: record-level (OWD → Role Hierarchy → Sharing Rules → Manual Sharing, each only adding access) and object/field-level (Profile as mandatory baseline + Permission Sets/Groups adding more) — both must be satisfied for a user to see and act on a record."

🔗 Continue Your Salesforce Interview Prep

🚀 Bookmark sfinterviewpro.com

1,500+ free Salesforce interview questions across 25+ topics. No paywall. No signup. Updated regularly with new company-specific posts.

Browse All Topics → More Company-Wise Questions →

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.

75 Salesforce Interview Questions Asked at Capgemini (2026) — L1 & L2 Rounds | SF Interview Pro

🔗 Related Interview Prep

📋 Capgemini Interview Pattern (L1 / L2)

📋 Topics Covered — 58 Questions

🔒 Section 1 — Security & Sharing Model

⚙️ Section 2 — Apex, Triggers & Governor Limits

⏳ Section 3 — Async & Batch Apex

💻 Section 4 — LWC Fundamentals

🔀 Section 5 — LWC Communication & Navigation

🔄 Section 6 — Flows & Automation

🔗 Section 7 — Integration & Named Credentials

🔍 Section 8 — SOQL & Reports

🎯 Section 9 — Scenario-Based & Miscellaneous

🔗 Continue Your Salesforce Interview Prep

New interview questions every week

Courses

Interview Prep

Popular Searches

Site