Interview Questions

Pagination: Query with LIMIT and OFFSET, load page by page Infinite scrolling: Use lightning-datatable enable-infinite-loading SOQL cursor: Use Database.query with cursor patterns in Apex Aggregate data: Don't show raw records — show summaries/charts Server-side filtering: Let users narrow down before fetching

Screen Flow — presents UI screens to users; can be embedded in pages or quick actions Record-Triggered Flow — fires on record insert/update/delete (before/after save) Schedule-Triggered Flow — runs on a schedule for a batch of records Platform Event-Triggered Flow — fires when a platform event message is received Autolaunched Flow (No Trigger) — invoked programmatically from Apex, other flows, processes Flow Orchestration — coordinates multiple flows for complex multi-step approvals

Before Save: Runs before the record is committed to the database. Can update the triggering record's fields without DML. Faster — same transaction. Cannot perform DML on other records. After Save: Runs after the record is committed. Can perform DML on other records, send emails, call subflows, call Apex actions. Slightly slower — separate transaction.

Use Flow when: Simple declarative logic, admin-maintainable, field updates, email sends, record creates with simple logic, no complex collections/loops needed. Use Trigger when: Complex business logic, bulk processing, cross-object logic with many records, callouts required, precise governor limit control, order of execution matters, performance is critical.

Both execute — Salesforce doesn't prevent it. The order of execution: Validation Rules → Before Triggers → After Triggers → Assignment Rules → Auto-Response Rules → Workflow Rules → Process Builder → Record-Triggered Flows (After Save) → Escalation Rules → Entitlements → Roll-Up Summaries → Parent workflows → Commit. Having both is not recommended for same logic — leads to complexity and potential double-execution.

Create an Apex class with a method annotated @InvocableMethod. The method must be public static, accept a List parameter, and can return a List. Then in Flow, add an 'Action' element and select your Apex class. public class FlowApexAction { @InvocableMethod(label='Get Account Name') public static List<String> getAccountName(List<Id> accountIds) { List<String> names = new List<String>(); for(Account a : [SELECT Name FROM Account WHERE Id IN :accountIds]) names.add(a.Name); return names; } } Only one @InvocableMethod allowed per Apex class. Return type must be List<> to support bulk flow invocations.

(1) If the flow is on a record page — use {!$Record.Id} as a resource variable. (2) Use a 'Get Records' element to query the Account. (3) Pass it as an input variable when launching the flow. (4) Use the output of a previous 'Create Records' or 'Get Records' element.

Yes — using a Subflow element. One flow can call another flow (must be an Autolaunched or Screen Flow). You can pass input/output variables between flows.

Not directly. You can call an @InvocableMethod from a flow, and that Apex method can internally call a @future method. So indirectly yes, through an invocable Apex wrapper.

Yes — using the External Services feature (Swagger/OAS spec-based) or by calling Apex @InvocableMethod that does the callout. Flows themselves use the Apex callout mechanism under the hood.

A flow that fires when a specific Platform Event is published. The flow processes each event message. Use cases: real-time integrations, event-driven automation, processing events from external systems without custom Apex subscribers.

Use Fault connectors on elements that can fail (DML, Apex, subflows). Route fault path to a custom notification or set error message. For screen flows, use Fault connectors to show custom error screens. Flow errors also send email to flow admin by default.