Salesforce Flow Interview Questions [2025] — Complete Guide with Real Examples

📅 Flow

Salesforce Flow Interview Questions — Complete Guide 2026

⚡ Salesforce Flow

Salesforce Flow Interview Questions — Complete Guide 2026

Flow Types · Builder · Elements · Resources · Debug · Fault Handling · Recursion · Apex vs Flow · Best Practices — All Explained for Interviews

Intermediate–Advanced 40 Questions

Questions Index

1What is Flow & Why We Need It 2Types of Flow 3Deleting a Flow 4Key Building Blocks 5What is Flow Builder? 6Flow Elements & Resources 7Debug in Flow 8Version Control in Flow 9LWC in Screen Flow 10Calling Apex Through Flow 11Flow Inside Another Flow 12Important Flow Actions 13$Record vs $Record__Prior 14Fast Field Update vs Actions 15Share Records Through Flow 16Order of Execution of Flows 17Immediate vs Async Path 18Validate if Flow is Scheduled 19Debug as Another User 20Schedule Frequency Options 21Record Variable vs Collection 22Pause & Resume Screen Flow 23Flow Distribution Methods 24Running User Context 25What is a Flow Interview? 26Transactions in Flow 27Flow Connectors 28Lookup Field in Screen Flow 29Fault Handling in Flow 30Redirect to Newly Created Record 31Lookup vs Fast Lookup 32Apex Annotation for Flow 33Non-Mandatory Dropdown 34Two Column Layout in Flow 35Account Type → Capture Date 36Dependent Picklist in Flow 37Benefits of Flow over Apex 38Advantages of Apex over Flow 39Flow Best Practices 40Avoid Recursion in Flow

Question 01

What is Salesforce Flow and why do we need it?

✅ Answer

Flow is Salesforce's most powerful declarative automation tool — it replaces Workflow Rules and Process Builder (both retired) and is the official Salesforce standard for automation. "Flow First, Apex Second." ⚡

📋 Types of Flow at a Glance

Flow Type	Trigger	Has UI?	Use Case
Screen Flow	User clicks button	✅ Yes	Guided wizards, forms
Record-Triggered Flow	Record create/update/delete	❌ No	Auto-updates, notifications
Schedule-Triggered Flow	Date + Time + Criteria	❌ No	Nightly jobs, reminders
Autolaunched Flow	Apex / Subflow / REST API	❌ No	Reusable background logic
Platform Event Flow	Platform Event received	❌ No	Real-time event-driven integration

✅❌ What Flow Actually Controls

✅Create / Update / Delete records declaratively — no code
✅Send emails, post Chatter, send custom notifications, submit approvals
✅Call Apex via @InvocableMethod for heavy lifting
✅Show UI Screen elements — multi-step guided wizards
❌Cannot do dynamic SOQL with runtime-built WHERE clauses
❌Cannot process 50,000+ records — need Batch Apex for that

🌍 Real World Example — XYZ Company

At XYZ Company, a Record-Triggered Flow fires when an Order is created and auto-assigns freight charges based on territory — replacing a manual email process. Result: 90% reduction in processing time, ₹13–15L annual savings, zero manual effort.

🔑 Key Points for Interviewer

🔥Workflow Rules and Process Builder are retired — Flow is the only declarative automation tool going forward
💡Official Salesforce stance: "Flow First, Apex Second"
💡Flow respects governor limits — same Apex limits apply
💡Record-Triggered Flows can run Before Save (zero DML) or After Save (full power)

🎤 One-Line Answer for Interview

"Salesforce Flow is the official declarative automation platform that replaced Workflow Rules and Process Builder — allowing Admins and Developers to automate complex business logic, UI screens, and integrations without code, following the 'Flow First, Apex Second' principle."

Question 02

What are the different types of Salesforce Flow?

✅ Answer

Salesforce has 5 Flow types — Screen Flow, Record-Triggered Flow, Schedule-Triggered Flow, Autolaunched Flow, and Platform Event-Triggered Flow — each designed for a specific trigger and use case. ⚡

📋 Flow Types Detailed Comparison

Flow Type	Default Context	Pause/Resume?	Called From
Screen Flow	User Mode	✅ Yes	Button / App Builder / URL
Record-Triggered Flow	System Without Sharing	❌ No	Record save event
Schedule-Triggered Flow	System Without Sharing	❌ No	Date + Time + Criteria
Autolaunched Flow	System Without Sharing	❌ No	Apex / Subflow / REST API
Platform Event Flow	System Without Sharing	❌ No	Platform Event published

✅❌ What Each Type Actually Controls

✅Screen Flow — only type with user interaction. Supports Pause/Resume. Cannot be called as Subflow.
✅Record-Triggered — Before Save or After Save. Most common type in production orgs.
✅Schedule-Triggered — Daily, Weekly, Once only. No native hourly option.
✅Autolaunched — no UI. Callable from Apex via Flow.Interview. Primary = Subflow logic.
❌Cannot call Screen Flow as a Subflow — must be Autolaunched type

🎤 One-Line Answer for Interview

"Salesforce has 5 Flow types — Screen Flow for user-facing wizards, Record-Triggered for record-change automation, Schedule-Triggered for time-based jobs, Autolaunched for reusable background logic called from Apex or other Flows, and Platform Event-Triggered for real-time integrations."

Question 03

Can we delete a Flow? Are deleted Flows recoverable?

⚠️ It Depends

You cannot delete an Active Flow — you must deactivate it first. Once deleted, Flows are NOT recoverable — no Recycle Bin for Flows. Permanent and irreversible. ⚠️

📋 Flow Version States

State	Can Delete?	Runs?	Can Reactivate?
Active	❌ No — deactivate first	✅ Yes	Already active
Inactive	✅ Yes	❌ No	✅ Yes
Obsolete (old versions)	✅ Yes	❌ No	❌ No
Invalid	✅ Yes	❌ No	❌ No

✅❌ What Deletion Actually Controls

✅Can delete Inactive and Obsolete versions to clean up org
❌Cannot delete Active Flow — must deactivate first
❌Deleted Flows do NOT go to Recycle Bin — permanently gone
⚠️Only backup: Export Flow as XML from Setup → Flows → Export
⚠️If Flow is referenced by a button or Apex — deletion breaks those references

🔑 Key Points for Interviewer

🔥Must deactivate before deleting — cannot delete Active flow directly
🔥Deleted Flows are NOT in Recycle Bin — permanent and irreversible
💡Always export XML before major changes — Setup → Flows → Export
💡For enterprise orgs — use Salesforce DX + Git to version control Flow XML metadata

🎤 One-Line Answer for Interview

"You cannot delete an Active Flow — you must deactivate it first — and once deleted, Flows are permanently gone with no Recycle Bin recovery, so always export the Flow XML as a backup before deleting."

Question 04

What are the key Building Blocks of a Flow?

✅ Answer

Every Flow is built using Elements, Connectors, and Resources — think of Elements as actions, Resources as data containers, and Connectors as the arrows connecting everything together. 🧱

📋 Elements — Apex Equivalents

Element	What It Does	Apex Equivalent
Get Records	Query records from database	SOQL SELECT
Create Records	Insert new records	DML insert
Update Records	Update existing records	DML update
Delete Records	Delete records	DML delete
Decision	Branch logic based on conditions	if / else if / else
Loop	Iterate through a collection	for loop
Assignment	Set variable values	variable = value
Screen	Show UI to user	Visualforce / LWC
Apex Action	Call Invocable Method	@InvocableMethod call
Subflow	Call another Autolaunched Flow	method call to another class

📋 Resources — All Types

Resource	Purpose	Changes at Runtime?
Variable	Store single value (Text, Number, Record)	✅ Yes
Collection Variable	Store list of records or values	✅ Yes
Constant	Fixed value — never changes	❌ No
Formula	Calculated expression (recalculates on reference)	✅ Recalculates
Text Template	Dynamic email/text body with merge fields	✅ Yes
Stage	Track Screen Flow progress steps	✅ Yes

✅❌ Golden Rules

🔥NEVER do DML inside a Loop — collect records → one bulk DML after loop ends
✅Get Records returns null if no records found — always handle with Decision element after
✅Text Templates are underused — perfect for dynamic email bodies with merge fields

🎤 One-Line Answer for Interview

"Flow building blocks are Elements (Get Records, Decision, Loop, Create Records, Screen, Apex Action), Resources (Variables, Collections, Formulas, Text Templates, Constants), and Connectors — together forming a visual programming language equivalent to Apex code."

Question 05

What is Flow Builder in Salesforce?

✅ Answer

Flow Builder is Salesforce's point-and-click visual canvas tool for creating, configuring, debugging, and managing all Flows — the IDE of Flow, just like VS Code is for Apex. 🛠️

📋 Flow Builder Key Sections

Section	What It Does
Toolbox (Left Panel)	All Elements and Resources available to drag onto canvas
Canvas (Center)	Visual workspace where elements are connected
Start Element	Defines trigger — Record change, Schedule, Screen, Platform Event
Properties Panel (Right)	Configure selected element — fields, conditions, values
Debug Button	Run Flow step-by-step with test data before activating
Activate Button	Makes Flow live in org

✅❌ What Flow Builder Controls

✅Create and edit all 5 Flow types from one unified interface
✅Debug execution step-by-step with real or test data — no deployment needed
✅Manage all versions — see version history, activate/deactivate
❌Cannot simulate bulk data — debug runs single record at a time
❌No built-in version diff — cannot compare what changed between versions
❌Cloud Flow Designer was the OLD retired tool — Flow Builder is the current one

🔑 Key Points for Interviewer

🔥Flow Builder is at Setup → Flows
💡Cloud Flow Designer is retired — mentioning it shows awareness of platform history
💡Elements with errors show in red — cannot save until all errors resolved
💡Always debug before activating — production best practice, no exceptions

🎤 One-Line Answer for Interview

"Flow Builder is Salesforce's visual point-and-click canvas tool — available at Setup → Flows — used to create, configure, debug, and manage all Flow types, replacing the retired Cloud Flow Designer."

Question 06

What is the difference between Flow Elements and Flow Resources?

✅ Answer

Elements are the action steps on the canvas that DO something — query data, make decisions, update records. Resources are data containers that STORE values used by those elements. Elements = Workers. Resources = Storage. 🧠

📋 Elements vs Resources

Feature	Elements	Resources
What it is	Action steps on the canvas	Data containers and values
Examples	Get Records, Decision, Loop, Screen	Variable, Collection, Formula, Constant
Apex Equivalent	Statements and method calls	Variables, constants, expressions
Visible on canvas?	✅ Yes — draggable boxes	❌ No — defined in Toolbox panel
Has connectors?	✅ Yes — arrows link elements	❌ No — referenced inside elements

✅❌ Critical Rules

🔥NEVER do DML inside a Loop — collect into Collection Variable inside loop → bulk DML after
✅Get Records null handling — always add Decision after Get Records to check if result is null
✅Input/Output Variables = how Flows talk to Apex, Screen LWCs, and other Flows
✅Formula Resources recalculate every time referenced — Variable stores a fixed point-in-time value

🎤 One-Line Answer for Interview

"Flow Elements are the action steps on the canvas that perform operations — Get Records (SOQL), Decision (if-else), Loop (for loop), Assignment (variable=value) — while Resources are data containers like Variables, Collections, Formulas, and Text Templates that Elements read from and write to."

Question 07

Why should you use Debug in Flow? What options does it offer?

✅ Answer

Flow Debug lets you run a Flow step-by-step with test data before activating — showing variable values and decision paths at every step — catching errors before they hit production. 🔍

📋 Debug Options

Debug Option	What It Does	When to Use
Run as Another User	Simulates Flow execution as a specific user — respects their profile, FLS, sharing	Catching permission and visibility issues
Roll Back Changes	Flow runs fully but all DML rolled back at the end	Testing DML flows safely without polluting data
Pass Input Variables	Simulate different data scenarios without real test records	Testing conditional logic paths

✅❌ Debug vs Activated Flow

✅Debug shows variable values at each step — impossible to see in live execution
✅Debug shows which Decision path was taken — YES or NO highlighted
✅"Run as Another User" catches FLS/sharing issues invisible when debugging as Admin
❌Cannot debug with bulk data — runs single record only
❌Cannot debug Guest User context — use Experience Cloud site preview instead

🌍 Real World Example — XYZ Company

At XYZ Company, the Quote Approval Flow worked as Admin but failed for Sales Reps. Debug with "Run as Another User" → found Margin__c field returned null → Sales Rep profile had no Read access on that field. Fixed FLS → issue resolved before going live. Debug saved a production incident.

🔑 Key Points for Interviewer

🔥"Run as Another User" is the most underused but most powerful debug feature
💡"Roll Back Changes" — safest way to test DML flows without corrupting real data
💡Always debug as a non-Admin end user before activating — not just as yourself
💡Deliberately pass bad/null data to test Fault Paths fire correctly

🎤 One-Line Answer for Interview

"Flow Debug runs a Flow step-by-step before activation — showing variable values and decision paths at each stage — with options to run as another user (catching permission issues), roll back DML changes (safe testing), and pass input variables (testing different scenarios)."

Question 08

How does Version Control work in Salesforce Flow?

✅ Answer

Every Save in Flow Builder creates a new version automatically. Only one version can be Active at a time. Old versions can be reactivated instantly for rollback — making Flow versioning very powerful. ⚙️

📋 Flow Version States

State	Runs?	Can Activate?	Can Delete?
Active	✅ Yes — live in org	Already active	❌ Deactivate first
Inactive	❌ No	✅ Yes	✅ Yes
Obsolete	❌ No (was active, now replaced)	❌ No	✅ Yes
Invalid	❌ No — has errors	❌ No	✅ Yes

✅❌ Flow Version Control — Key Facts

✅Every Save = new version — V1, V2, V3 — automatic
✅Can reactivate any old Inactive version — instant rollback in 30 seconds
❌No built-in diff tool — cannot compare what changed between versions
❌No commit messages — use Description field to document changes
❌No Git branching — use Salesforce DX + Git for enterprise version control

🔑 Key Points for Interviewer

🔥Rollback = just reactivate old version — fastest recovery in a production incident
💡Keep last 2–3 versions as rollback safety net — delete very old obsolete versions
💡For enterprise orgs — Salesforce DX + Git stores Flows as XML metadata for real version control
💡Always export XML before major restructuring — Setup → Flows → Export

🎤 One-Line Answer for Interview

"Flow version control creates a new version on every save — only one Active at a time — with instant rollback by reactivating any old Inactive version, and for true Git-based version control, Flows are managed as XML metadata via Salesforce DX."

Question 09

Can we use LWC (Lightning Web Components) in Screen Flow?

✅ YES

Yes — LWC can be embedded in Screen Flow as Flow Screen Components. This gives you the simplicity of Flow + the full power of custom UI. The key requirement: target: lightning__FlowScreen in the meta XML. 🔥

📋 Standard vs Custom Screen Components

Type	Examples	Code Needed?
Standard Flow Components	Text Input, Picklist, Number, Checkbox, File Upload	❌ No
Custom LWC Components	Custom Lookup, Data Table, Signature Pad	✅ Yes
AppExchange Components	Pre-built from Salesforce Labs / ISVs	❌ No

✅❌ LWC in Screen Flow — Key Requirements

🔥Set target: lightning__FlowScreen in meta XML — without this LWC won't appear in Flow Builder
✅Use FlowAttributeChangeEvent to pass output values from LWC back to Flow
✅Use FlowNavigationNextEvent to programmatically navigate Flow forward from LWC
✅Mark output properties with role="outputOnly" in meta XML
❌Cannot access Flow variables directly — only via explicit Input/Output properties

🌍 Real World Example — XYZ Company

At XYZ Company, a customLookup LWC with search-as-you-type was built (standard Flow has no lookup) and embedded in the Quote creation Screen Flow. Output selectedRecordId stored in a Flow variable → passed to Create Records element. Full lookup UX without leaving the Flow framework.

🎤 One-Line Answer for Interview

"Yes — LWC can be embedded in Screen Flow by setting target to lightning__FlowScreen in the meta XML and using FlowAttributeChangeEvent to pass data back to Flow — enabling fully custom UI experiences like lookup fields and data tables within the Flow framework."

Question 10

Can we call an Apex Class through Flow? Which annotation is used?

✅ YES

Yes — using @InvocableMethod on a public static Apex method exposes it to Flow as an Action element. Use @InvocableVariable on inner class properties for input/output fields. 🔗

📋 @InvocableMethod Parameters

Parameter	What It Does	Example
`label`	Name shown in Flow Builder action search	'Calculate Freight'
`description`	Tooltip shown in Flow Builder	'Calculates freight charge based on territory'
`category`	Groups actions in Flow Builder	'Order Management'
`callout=true`	Required if method makes HTTP callouts	`callout=true`

✅❌ Key Rules

🔥Method must be public static — non-negotiable, instance methods not supported
🔥Input and output must always be List<> — even for single record operations
✅callout=true required if Apex makes HTTP callout — otherwise Flow throws runtime error
❌Cannot use @future inside Invocable Method — use Queueable Apex inside instead
❌Governor limits are shared — Apex called from Flow shares the same transaction SOQL/DML budget

🌍 Real World Example — XYZ Company

At XYZ Company, the IndiaMART Scheduled Flow calls an @InvocableMethod Apex class that makes the HTTP callout to IndiaMART REST API. Flow handles the schedule and orchestration — Apex handles the actual API call and JSON parsing. Flow does the WHAT. Apex does the HOW.

🎤 One-Line Answer for Interview

"Yes — @InvocableMethod on a public static Apex method exposes it to Flow as an Action element, with @InvocableVariable on inner class properties defining input/output fields — always using List<> for bulk-safe design, and adding callout=true if the method makes HTTP requests."

Question 11

How do you call a Flow inside another Flow (Subflow)?

✅ Answer

Use the Subflow Element in Flow Builder. The child Flow must be an Active Autolaunched Flow. Data passes between parent and child via Input and Output Variables. 🔄

📋 Subflow — Key Rules

Rule	Detail
Child Flow Type	Must be Autolaunched Flow — cannot call Screen Flow as Subflow
Child Flow Status	Must be Active — calling Inactive = runtime error
Data Exchange	Input Variables (Parent → Child), Output Variables (Child → Parent)
Governor Limits	Shared across Parent + all Child Flows in same transaction
Circular Calls	❌ Not allowed — Flow A → Flow B → Flow A = error
Nested Subflows	✅ Supported — Child can call another Subflow

✅❌ What Subflow Actually Controls

✅Best pattern for reusable logic — change child once, updates all parent Flows
✅Parent can call multiple Subflows in sequence or inside a Loop
❌Child variables NOT auto-visible in Parent — must explicitly map via Input/Output Variables
❌Cannot call Record-Triggered or Scheduled Flows as Subflow — Autolaunched only

🌍 Real World Example — XYZ Company

At XYZ Company, a Chatter Notification Autolaunched Flow was built once and called from 8 different parent Flows. When notification template changed → updated child Flow once → all 8 parent Flows automatically used the new template. DRY principle applied to Flow.

🎤 One-Line Answer for Interview

"Call a Flow from another using the Subflow element — the child must be an Active Autolaunched Flow — with data exchanged via Input/Output Variables — enabling reusable modular logic that can be called from multiple parent Flows, sharing the same governor limit transaction."

Question 12

What are the important Actions available in Salesforce Flow?

✅ Answer

Flow supports built-in Core Actions covering emails, approvals, Chatter, custom notifications, platform events, Apex calls, and Subflows — all configurable on the canvas without code. 🎯

📋 All Important Actions

Action	What It Does	Key Requirement
Send Email	Send email using template or custom body	Can use Email Templates or Text Template resource
Email Alert	Trigger existing Workflow Email Alert	Alert must exist in Setup → Email Alerts
Submit for Approval	Submit record into Approval Process	Approval Process must be Active for that object
Post to Chatter	Post message on record or user feed	Chatter must be enabled in org
Send Custom Notification	Push notification to bell icon + mobile	Custom Notification Type must be created in Setup first
Apex Action	Call @InvocableMethod Apex class	Method must be public static with @InvocableMethod
Subflow	Call another Autolaunched Flow	Child Flow must be Active + Autolaunched type
Publish Platform Event	Fire a Platform Event for integrations	Platform Event object must exist

✅❌ Key Distinctions

🔥Send Email vs Email Alert — Send Email builds body in Flow. Email Alert reuses existing Workflow Email Alert template.
✅Custom Notification requires Custom Notification Type created in Setup FIRST — common mistake in interviews
✅Submit for Approval from Flow = fully headless — user never has to click Submit button manually

🎤 One-Line Answer for Interview

"Important Flow actions include Send Email, Submit for Approval, Post to Chatter, Send Custom Notification (needs Custom Notification Type in Setup), Publish Platform Event, Apex Invocable Method calls, and Subflow — covering communication, approvals, integrations, and custom logic end-to-end."

Question 13

What is the difference between $Record and $Record__Prior in Flow?

✅ Answer

In Record-Triggered Flows, {!$Record} = current/new field values. {!$Record__Prior} = previous/old field values before the change. Flow's equivalent of Trigger.new and Trigger.old. 📌

📋 $Record vs $Record__Prior

Feature	{!$Record}	{!$Record__Prior}
Contains	Current / new field values	Previous / old field values
Apex Equivalent	Trigger.new[0]	Trigger.old[0]
Available on Create	✅ Yes	❌ NULL — nothing existed before
Available on Update	✅ Yes	✅ Yes
Available on Delete	✅ Yes	✅ Yes
Before Save Flow	✅ Yes	✅ Yes
After Save Flow	✅ Yes	✅ Yes

✅❌ Key Use Cases

🔥Entry Condition: {!$Record.Stage__c} ≠ {!$Record__Prior.Stage__c} — fires ONLY when Stage actually changes
✅Using $Record__Prior in Entry Conditions = biggest performance optimization for Record-Triggered Flows
⚠️$Record__Prior is NULL on Create — always handle with Decision or trigger on Update only

🌍 Real World Example — XYZ Company

At XYZ Company, the Order Confirmation Flow entry condition: {!$Record.Status__c} = "Confirmed" AND {!$Record__Prior.Status__c} ≠ "Confirmed" — fires ONLY when Status first becomes Confirmed. Without this, 500+ Chatter posts fired on every bulk Order edit!

🎤 One-Line Answer for Interview

"$Record holds the current new values (Trigger.new equivalent) and $Record__Prior holds the previous old values before change (Trigger.old equivalent) — using them together in Entry Conditions is the most powerful way to fire Record-Triggered Flows only when specific field changes actually occur."

Question 14

What is the difference between Fast Field Update and Actions & Related Records?

✅ Answer

Fast Field Update = Before Save — updates the triggering record with zero extra DML. Actions & Related Records = After Save — full power to update related records, call Apex, send emails. ⚡

📋 Before Save vs After Save

Feature	Fast Field Update (Before Save)	Actions & Related Records (After Save)
When it runs	Before record committed to DB	After record committed to DB
Apex Equivalent	before insert / before update trigger	after insert / after update trigger
Update triggering record?	✅ Via Assignment — ZERO extra DML	⚠️ Needs Update Records element
Update related records?	❌ No	✅ Yes
Call Apex / Send Email?	❌ No	✅ Yes
Add Custom Error (block save)?	✅ Yes	❌ No — already saved
HTTP Callouts?	❌ No	✅ Via Async Path

🌍 Real World Example — XYZ Company

At XYZ Company: Before Save Flow auto-calculates Freight Charge on Order save (zero DML overhead). After Save Flow submits for Approval, posts Chatter, sends customer email, and syncs to Business Central — all triggered after Order is safely committed to DB.

🔑 Key Points for Interviewer

🔥Before Save = fastest option for same-record updates — zero extra DML, always use this first
🔥Cannot add Custom Error in After Save — record already committed — too late to block
💡Cannot call Apex in Before Save — Salesforce restriction — Before Save is the fast synchronous path
💡HTTP Callouts in After Save must go in the Async Path — cannot mix callout + DML in same transaction

🎤 One-Line Answer for Interview

"Fast Field Update (Before Save) updates the triggering record with zero extra DML and can block saves with custom errors — while Actions and Related Records (After Save) gives full access to create/update related records, send emails, call Apex, and submit approvals after the record is safely committed."

Question 15

Can records be shared with users through Flow?

✅ YES

Yes — using the "Grant Record Access" built-in Flow Action which creates Manual Shares at runtime. You can also Revoke Record Access using the corresponding action. 🔐

📋 Sharing Methods in Flow

Method	What It Does	Use Case
Grant Record Access (Action)	Creates Manual Share on a record	Share with specific user/group at runtime
Revoke Record Access (Action)	Removes Manual Share from record	Remove access when condition changes
Transfer Ownership	Change OwnerId on record	New owner gets full access automatically

✅❌ What Flow Sharing Controls

✅Can set Access Level — Read Only or Read/Write
✅Works with Users, Public Groups, Roles, Role + Subordinates
❌OWD must be Private or Public Read Only — if OWD is Public Read/Write, sharing is irrelevant
❌Flow creates Manual Shares only — custom RowCause requires Apex Managed Sharing

🎤 One-Line Answer for Interview

"Yes — records can be shared through Flow using the Grant Record Access action which creates dynamic Manual Shares at runtime, with Revoke Record Access removing that access when conditions change — and Apex Managed Sharing needed for custom sharing reasons beyond Manual Share."

Question 16

Can we set the Order of Execution of Record-Triggered Flows?

✅ YES — Since Winter '22

Yes — set the Trigger Order (1–2000) on the Start Element of each Flow. Lower number = runs first. Flows without a number run last. Before Save and After Save have independent ordering. ⚙️

📋 Trigger Order Key Facts

Property	Detail
Range	1 to 2000
Lower number	Runs FIRST
No order set (default)	Runs LAST — after all numbered Flows
Same number on two Flows	Salesforce picks order — unpredictable
Where to set	Flow Builder → Start Element → Advanced → Trigger Order
Before Save vs After Save	Each has its OWN independent ordering

✅❌ Best Practices

🔥Use gaps of 10 (10, 20, 30) — not 1, 2, 3 — allows inserting new Flows without renumbering
✅Validation Flows first (lowest number) → Calculation Flows → Integration Flows last
✅Document Trigger Order in Flow Description field — dependency map for future admins

🌍 Real World Example — XYZ Company

At XYZ Company, Order Before Save Flows: Order 10 = KYC Validation (catches errors first), Order 20 = Quote Stage Validation, Order 30 = Freight Calculation. Before ordering, Freight was calculated before KYC validation — freight calculated even for invalid orders!

🎤 One-Line Answer for Interview

"Yes — Trigger Order (1–2000) on the Start Element controls execution sequence where lower runs first, Before Save and After Save have independent ordering, flows without a number run last, and gaps of 10 are recommended to allow inserting new flows without renumbering."

Question 17

What are the two paths in a Record-Triggered Flow? Explain Immediate vs Async path.

✅ Answer

The two paths are Immediate Path (synchronous — same transaction as record save, shared limits) and Asynchronous Path (new transaction after original completes — fresh limits, HTTP callouts allowed). 🔀

📋 Immediate vs Async Path

Feature	Immediate Path	Asynchronous Path
When it runs	Same transaction as record save	New transaction after original completes
HTTP Callouts allowed?	❌ No (if DML also present)	✅ Yes — clean transaction
Governor Limits	Shared with original transaction	✅ Fresh limits — new transaction
Blocks record save?	✅ Errors roll back save	❌ No — record already saved
User waits for it?	✅ Yes	❌ No — user moves on immediately
Apex Equivalent	Synchronous Apex	@future / Queueable Apex

✅❌ When to Use Which

⚡Immediate Path: Update related records, submit approval, post Chatter, time-sensitive operations
🔄Async Path: HTTP callouts to external systems, heavy processing needing fresh governor limits
🔥HTTP Callout + DML cannot be in same transaction — Async Path is the solution

🌍 Real World Example — XYZ Company

At XYZ Company: Immediate Path — Submit Approval + Post Chatter (must happen right away). Async Path — Business Central HTTP callout + IndiaMART sync (callout + DML cannot mix, and user doesn't need to wait for BC API response).

🎤 One-Line Answer for Interview

"The Immediate Path runs synchronously in the same transaction with shared governor limits — while the Asynchronous Path runs in a brand new separate transaction with fresh limits — enabling HTTP callouts combined with DML without blocking the user experience."

Question 18

From where can we validate whether a Flow is scheduled or not?

✅ Answer

Validate from Setup → Scheduled Jobs (primary), Setup → Paused and Waiting Interviews, and the Flow Detail Page. Active status alone does NOT confirm a Flow is scheduled. 📋

📋 All Validation Locations

Location	Path	What You See
Scheduled Jobs (Primary)	Setup → Scheduled Jobs	Next run time, frequency, delete option
Paused and Waiting Interviews	Setup → Paused and Waiting Interviews	Queued / paused / stuck Flow interviews
Flow Detail Page	Setup → Flows → Click Flow Name	Flow type confirmation, Active status

✅❌ Validation Checklist

1️⃣Setup → Flows → Confirm type = "Schedule-Triggered" and Status = "Active"
2️⃣Setup → Scheduled Jobs → Confirm job exists with correct frequency and next run time
3️⃣Setup → Paused and Waiting Interviews → Check for queued or stuck interviews
🔥Active status alone ≠ Flow is scheduled — must check Scheduled Jobs separately

🎤 One-Line Answer for Interview

"Validate a scheduled Flow from Setup → Scheduled Jobs (shows next run time and frequency), Setup → Paused and Waiting Interviews (shows queued interviews), and the Flow Detail Page to confirm type is Schedule-Triggered and status is Active — Active status alone does not confirm scheduling."

Question 19

Can we debug a Flow as another user?

✅ YES

Flow Builder Debug has a built-in "Run As" option — debug any Flow as any active user, seeing exactly what that user sees with their permissions, profile, and record sharing. Most underused debug feature! 👤

📋 What "Run As" Catches

Issue Type	What Run As Detects
FLS Issues	Field not visible to user → Get Records returns null for that field
Sharing Issues	User can't see record → Get Records returns 0 records
Profile Permission Issues	User can't create records → Create Records element fails
Record Type Differences	Different picklist values appear per user's record type

✅❌ Key Rules

🔥Most underused — most developers only debug as Admin and miss permission issues entirely
✅Roll Back Changes works with Run As too — safe to test DML as another user
❌Cannot debug as Guest User — use Experience Cloud Site preview for guest flow testing
✅Always do at least one debug run as a non-Admin end user before going live

🎤 One-Line Answer for Interview

"Yes — Flow Builder's Debug mode has a Run As option to debug as any active user — respecting their profile permissions, field-level security, and record sharing — making it the most powerful way to catch permission and access issues before deploying to production."

Question 20

What are the frequency options in a Schedule-Triggered Flow?

✅ Answer

Only 3 frequency options: Once (specific date+time), Daily, and Weekly. There is NO native hourly option — that requires a Scheduled Apex workaround. ⏰

📋 Frequency Options

Frequency	Options Available	Use Case
Once	Specific Date + Time	One-time data migrations, single run jobs
Daily	Start Date + Time	Nightly jobs, daily reports
Weekly	Day(s) of week + Time	Monday + Friday reminders, weekly digests
Hourly	❌ NOT available natively	Use Scheduled Apex + Autolaunched Flow workaround
Monthly	❌ NOT available natively	Use Daily with date formula condition

💡 Hourly Workaround

✅Scheduled Apex with cron expression '0 0 * * * ?' → calls Autolaunched Flow via Flow.Interview every hour
✅Platform Event fired every hour from external system → Platform Event-Triggered Flow fires

🌍 Real World Example — XYZ Company

At XYZ Company, IndiaMART Lead Sync needed hourly execution — Scheduled Flow only offers Daily/Weekly/Once. Solution: Scheduled Apex runs every hour via cron → calls IndiaMART Autolaunched Flow via Flow.Interview. Best of both worlds — Apex scheduling power + Flow logic.

🎤 One-Line Answer for Interview

"Schedule-Triggered Flow supports three frequency options — Once for a one-time run, Daily, and Weekly — with no native hourly option, requiring a Scheduled Apex workaround that calls an Autolaunched Flow via Flow.Interview on a cron schedule."

Question 21

What is the difference between a Record Variable and a Record Collection Variable?

✅ Answer

Record Variable = ONE single record (like Account acc in Apex). Record Collection Variable = MULTIPLE records as a List (like List<Account> in Apex). 📦

📋 Record Variable vs Collection

Feature	Record Variable	Record Collection Variable
Stores	Single sObject record	List of sObject records
Apex Equivalent	`Account acc`	`List<Account> accs`
Get Records → How	First Record Only option	All Records option
Loop input	❌ Cannot loop directly	✅ Loop iterates through it
Loop current item	✅ Auto-created Record Variable per iteration	❌ Not applicable
Bulk DML	Single record DML	✅ Bulk DML in one operation

🔥 Golden Rule — Correct Loop Pattern

🔥NEVER DML inside a Loop — Assignment add to Collection Variable inside loop → one bulk DML after loop ends
✅Get Records "First Record Only" → Record Variable
✅Get Records "All Records" → Collection Variable → Feed into Loop
✅Current item in Loop = Record Variable (auto-created) → work on it → add to output collection

🎤 One-Line Answer for Interview

"Record Variable stores a single sObject like Account acc in Apex (Get Records First Record Only) while Record Collection Variable stores multiple records like List<Account> (Get Records All Records) — with the golden rule being to collect records inside a Loop and do one bulk DML after, never inside the Loop."

Question 22

Can we Pause and Resume a Screen Flow?

✅ YES — Screen Flow Only

Screen Flow supports Pause and Resume — user saves progress mid-flow and resumes later from exactly where they left off, even in a different browser session. State saved to Salesforce DB. 💾

📋 Pause vs Wait Element

Feature	Pause (Screen Flow)	Wait Element (Record-Triggered)
Initiated by	User — clicks Pause button	System — waits for time/event condition
Flow Type	Screen Flow only	Record-Triggered Flow
State saved to DB?	✅ Yes — Setup → Paused Interviews	✅ Yes — queued interview
Who resumes?	Same user who paused	System — when condition met
Expiry	30 days	Configurable

✅❌ Key Restrictions

✅Screen Flow only — no other Flow type supports user-initiated Pause
❌Guest Users cannot pause — no authenticated user context to save interview to
❌DML executed before pause is NOT rolled back — record changes persist even if user never resumes
🔥Pause = user-initiated | Wait Element = system-initiated — key distinction for interviews
✅Admin can view and delete stuck paused interviews at Setup → Paused and Waiting Interviews

🎤 One-Line Answer for Interview

"Yes — Screen Flow supports Pause and Resume where users save current progress including variable values and screen position — with paused interviews stored in Salesforce for up to 30 days, visible to Admins at Setup → Paused and Waiting Interviews, and DML executed before pause not rolled back."

Question 23

What are the different Flow Distribution Methods?

✅ Answer

Salesforce provides multiple ways to distribute a Flow — App Builder embeds, buttons, tabs, utility bar, Experience Cloud portals, direct URLs, and programmatic Apex calls. 🌐

📋 All Distribution Methods

Method	Flow Type	Audience
Lightning App Builder	Screen Flow	Internal — embedded on record/app/home page
Quick Action / Button	Screen Flow	Internal — on-demand trigger on a record
Direct Flow URL	Screen Flow	Internal — shareable link /flow/API_Name
Custom Tab	Screen Flow	Internal — standalone navigation item
Utility Bar	Screen Flow	Internal — always-on sidebar tool
Experience Cloud	Screen Flow	External — customer/partner portal
Salesforce Mobile App	Screen Flow	Mobile users / field reps
Apex (Flow.Interview)	Autolaunched	Programmatic — from triggers/batch/queueable
Subflow Element	Autolaunched	Other Flows — reusable logic modules

✅❌ Key Rules

🔥User must have "Run Flows" permission on their Profile or Permission Set — without this, no distribution method works
✅Experience Cloud = only way to share Screen Flows with external/unauthenticated users
✅Utility Bar = best for repeated tools users need without leaving current page

🎤 One-Line Answer for Interview

"Flow can be distributed via Lightning App Builder, Quick Actions, Utility Bar, Custom Tabs, Experience Cloud for external users, Direct URL for sharing, Salesforce Mobile for field users, and programmatically via Apex or Subflow — each requiring the user to have the Run Flows permission."

Question 24

Explain Running User Context in Salesforce Flow

✅ Answer

Every Flow runs in a user context that determines whose permissions, FLS, and sharing rules are applied. Two modes: System Mode (bypasses restrictions) and User Mode (respects running user's permissions). 🔐

📋 Running Modes Comparison

Mode	Respects FLS?	Respects Sharing?	Default For
System Without Sharing	❌ Bypassed	❌ Bypassed	Record-Triggered, Scheduled, Autolaunched Flows
System With Sharing	❌ Bypassed	✅ Respected	Configure explicitly in Flow Properties
User Mode	✅ Respected	✅ Respected	Screen Flow (default)

✅❌ Key Rules

🔥Screen Flow defaults to User Mode — most secure for user-facing flows
🔥Record-Triggered defaults to System Without Sharing — sees all records regardless of user
✅Configure in Flow Properties → "How to Run the Flow" section
❌Running context does NOT auto-inherit to Subflows — configure each Flow independently
❌Apex called from Flow has its own sharing model — Flow context doesn't transfer to Apex

🎤 One-Line Answer for Interview

"Flow running context determines whose permissions apply — System Without Sharing bypasses all FLS and sharing, System With Sharing respects record visibility but ignores FLS, and User Mode fully respects the running user's permissions — Screen Flows default to User Mode while Record-Triggered Flows default to System Without Sharing."

Question 25

What is a Flow Interview in Salesforce?

✅ Answer

A Flow Interview is a single running instance of a Flow. Flow = the blueprint/class definition. Flow Interview = the actual running execution/object instance. Every trigger creates a new Flow Interview. 🏃

📋 Flow vs Flow Interview

Feature	Flow (Definition)	Flow Interview (Instance)
What it is	Blueprint / Template	Actual running execution
Created by	Admin / Developer in Flow Builder	Salesforce at runtime when triggered
Contains	Elements, Resources, Logic structure	Runtime variable values, current position
Apex Equivalent	Apex Class definition	Apex Class instance (new MyClass())
Visible in Setup	Setup → Flows	Setup → Paused and Waiting Interviews

✅❌ Interview Lifecycle

✅Created: User triggers / Record saves / Schedule fires
✅Paused: User paused Screen Flow — saved to DB — visible in Paused Interviews
✅Finished: Flow reached End element — interview destroyed from memory
🔥Always set a meaningful Interview Label: "Order {!OrderNumber} — {!$Flow.CurrentDateTime}" — helps Admin find stuck interviews
❌Paused interviews expire after 30 days — inform users to resume before expiry

🎤 One-Line Answer for Interview

"A Flow Interview is a single runtime instance of a Flow — equivalent to a class instance from a class definition in Apex — created each time a Flow is triggered, holding its own variable values and execution position, with paused interviews persisted to the database and visible at Setup → Paused and Waiting Interviews."

Question 26

Explain Transactions in Salesforce Flow. When does a transaction start?

✅ Answer

A Transaction is a single unit of work that either fully commits or fully rolls back. Flow executes within a transaction — sharing governor limits with all Apex triggers and automations running at the same time. ⚙️

📋 Transaction Boundaries in Flow

Flow Scenario	Same Transaction?	New Transaction?
Before Save Flow	✅ Same as record save	—
After Save Flow (Immediate Path)	✅ Same as record save	—
After Save Flow (Async Path)	—	✅ New — after original completes
Scheduled Flow run	—	✅ New — independent transaction
Subflow called from Flow	✅ Same as parent Flow	—

✅❌ Critical Rules

🔥All automation shares governor limits — Flow + Apex + WFR all share the same SOQL/DML budget
✅Async Path = new transaction → fresh limits + independent rollback — biggest advantage
✅Fault Path prevents rollback — catches errors so transaction can still commit gracefully
❌Flow has no Savepoints — error = entire transaction rolls back (unless Fault Path catches it)
🔥DML inside Loop = transaction killer — hits DML limits fast — always collect + bulk DML

🎤 One-Line Answer for Interview

"A Flow transaction starts when a record save or trigger fires — all automation including Flows and Apex share the same governor limits in that transaction — and either fully commits or completely rolls back on unhandled error, with the Async Path being the key tool to start a fresh transaction with new limits for callouts."

Question 27

What are Flow Connectors?

✅ Answer

Flow Connectors are the arrows on the canvas connecting elements — defining the execution path from one element to the next. Without connectors, elements are isolated boxes. With connectors, they form logic. ➡️

📋 Types of Flow Connectors

Connector Type	Style	Purpose
Regular Connector	Solid arrow	Standard next step — go here after this element
Outcome Connector	Labeled arrow	Decision element paths — YES / NO / Default
Fault Connector	Red dashed arrow	Error path — fires when element fails
Next Connector (Loop)	Loop arrow back	Returns to Loop element for next iteration
After Last Connector	Exit arrow	Exits Loop after all iterations complete
Go To Connector	Jump arrow	Skip to any element — merge multiple paths

✅❌ Common Mistakes

🔥No Default Outcome on Decision → Flow has no path for unexpected values → runtime error
🔥No Fault Connector on DML → DML failure → unhandled error → entire transaction rolls back
🔥Missing After Last on Loop → Flow doesn't know where to go after last iteration → error
✅Go To connector — newer feature — merges paths to same element without duplicating elements

🎤 One-Line Answer for Interview

"Flow Connectors are the arrows defining execution paths — Regular for sequential flow, Outcome connectors for Decision branching, Fault connectors (red dashed) for error handling, Next and After Last for Loop control, and Go To connectors for merging paths — making them the backbone of how Flow logic executes from start to end."

Question 28

How to create a Lookup field in Screen Flow?

⚠️ No Native Lookup Exists

Salesforce does NOT have a native Lookup component in Screen Flow. Options: Record Choice Set (simple dropdown, 200 limit), Custom LWC Lookup (full search-as-you-type), or AppExchange components. 🔍

📋 All Options Compared

Option	UX	Search-as-you-type	Code Needed?	Limit
Record Choice Set	⚠️ Basic dropdown	❌ No	❌ No	200 records max
Custom LWC Lookup	🔥 Full lookup UX	✅ Yes	✅ Yes	None
AppExchange Component	✅ Good	✅ Yes	❌ No	Third party

✅❌ Custom LWC Lookup Requirements

🔥Set target: lightning__FlowScreen in meta XML — mandatory to appear in Flow Builder
✅Use FlowAttributeChangeEvent to pass selected record ID back to Flow
✅Mark output properties with role="outputOnly" in meta XML
❌Record Choice Set limit — 200 records max, no search-as-you-type — not suitable for large datasets

🎤 One-Line Answer for Interview

"Salesforce has no native lookup in Screen Flow — so we use Record Choice Set for a basic 200-record dropdown, or build a custom LWC with lightning__FlowScreen target and FlowAttributeChangeEvent for full search-as-you-type lookup functionality — passing the selected record ID back as an output variable."

Question 29

How do you handle Faults / Errors in Salesforce Flow?

✅ Answer

Use Fault Paths — red dashed connectors on risky elements — to catch runtime errors gracefully. They are Flow's equivalent of try-catch in Apex. Without them, errors crash the entire transaction. 🛡️

📋 Elements That Support Fault Path

Element	Fault Path Available?
Create Records	✅ Yes
Update Records	✅ Yes
Delete Records	✅ Yes
Apex Action	✅ Yes
Subflow	✅ Yes
Send Email / Custom Notification	✅ Yes
Decision / Assignment / Loop	❌ These cannot fail
Get Records	❌ Returns null — not an error — handle with Decision

✅❌ Fault Handling Patterns

✅Pattern 1 — Log + Notify: Fault → Assignment stores {!$Flow.FaultMessage} → Create Flow_Error_Log__c record → Send email to admin
✅Pattern 2 — User-Friendly Error (Screen Flow): Fault → Assignment → Screen element with friendly message + retry option
❌Get Records has NO Fault Path — returns null if no records found → handle with Decision element instead

🌍 Real World Example — XYZ Company

At XYZ Company, the IndiaMART Scheduled Flow hit API timeout at 11 PM. Fault Path caught it: stored {!$Flow.FaultMessage} → created Flow_Error_Log__c → sent admin email. Flow ended gracefully, error logged, next hourly run attempted automatically. Zero data corruption.

🎤 One-Line Answer for Interview

"Fault handling in Flow uses Fault Paths — red dashed connectors on DML elements and Apex Actions — catching runtime errors using {!$Flow.FaultMessage} to log the error, notify admins, and end gracefully instead of crashing the entire transaction."

Question 30

How to redirect a Flow to the Newly Created Record after completion?

✅ Answer

Create Records element returns the new record's ID automatically. Store it in a variable via "Manually assign variables (advanced)", then use a Navigate Action pointing to that ID to redirect the user. 🎯

📋 Step-by-Step Solution

Step	What to Do	Key Config
Step 1	Create Text Variable	API Name: NewRecordId \| Available for Output: ✅
Step 2	Configure Create Records element	Select "Manually assign variables (advanced)" → map ID to {!NewRecordId}
Step 3	Add Navigate Action after Create Records	Type: Record \| Record ID: {!NewRecordId}
Step 4	User lands on new record page	Browser navigates to newly created record ✅

✅❌ Key Points

🔥Must select "Manually assign variables (advanced)" — without this, the ID is not captured
✅Navigate Action supports: Record, List View, App Page, Web Page
✅Always add Fault Path on Create Records — if creation fails, Navigate never fires
❌Flow Finish Behavior in Properties cannot use dynamic runtime IDs — only works for static targets

🎤 One-Line Answer for Interview

"Configure Create Records with 'Manually assign variables (advanced)' to capture the new record ID into a Text variable, then add a Navigate Action of type Record pointing to that variable — so the user lands directly on the newly created record page when Flow finishes."

Question 31

What is the difference between Lookup and Fast Lookup in Flow?

⚠️ Legacy — Old Cloud Flow Designer

Both Record Lookup and Fast Lookup were elements in the retired Cloud Flow Designer. Both are now replaced by a single "Get Records" element in modern Flow Builder. ⚙️

📋 Old vs New Comparison

Feature	Record Lookup (Old)	Fast Lookup (Old)	Get Records (Current)
Status	⛔ Retired	⛔ Retired (merged in)	✅ Active
Returns	Individual field values → separate variables	Entire sObject record	Record Variable or Collection
Performance	🐢 Slow and verbose	⚡ Fast	⚡ Fast (uses Fast Lookup approach)
Multiple records?	❌ First only	✅ Yes	✅ Choose First Record or All Records

✅ Why Fast Lookup Won

❌Record Lookup — one separate variable per field → verbose, hard to maintain, slow
✅Fast Lookup — entire record stored in one variable → access any field at any time
✅Modern Get Records = Fast Lookup approach — one record or collection variable holds complete record(s)

🎤 One-Line Answer for Interview

"Record Lookup stored individual field values into separate variables making it slow and verbose, while Fast Lookup stored the entire sObject in one variable — both are retired and replaced by the modern Get Records element in Flow Builder which uses the Fast Lookup approach of complete record storage."

Question 32

What annotations must be implemented in Apex to use it in Flow?

✅ Answer

@InvocableMethod on the Apex method exposes it to Flow. @InvocableVariable on inner class properties defines the input/output fields visible in Flow Builder. These two together = full Apex-Flow integration. 🔗

📋 Annotations Summary

Annotation	Applied On	Key Requirement
`@InvocableMethod`	Apex method	Must be public static — instance methods not supported
`@InvocableVariable`	Inner class properties	Must be public — defines fields shown in Flow Builder

✅❌ Critical Rules

🔥Method must be public static — most common mistake
🔥Always use List<> for both input and output — even for single value — makes it bulk-safe
✅Add callout=true to @InvocableMethod if method makes HTTP callouts
✅Add required=true to @InvocableVariable to make Flow input mandatory
❌Cannot use @future inside — use Queueable Apex for async within Invocable Methods
✅Test class still required — Invocable Methods need @isTest coverage like any Apex

🎤 One-Line Answer for Interview

"@InvocableMethod on a public static method exposes it to Flow as an Action element, and @InvocableVariable on inner class properties defines the input/output fields visible in Flow Builder — with List<> always required for both input and output for bulk-safe design."

Question 33

How to create a Non-Mandatory Dropdown field in Screen Flow?

✅ Answer

Add a Picklist component to the Screen element, toggle the "Required" property OFF, add a "-- None --" first choice with empty value, and handle the potentially null output with a Decision element downstream. 📋

📋 Dropdown Options in Screen Flow

Component	Multi-select?	Required Toggle	Best For
Picklist	❌ Single only	✅ Toggle OFF	Small value sets
Multi-Select Picklist	✅ Yes	✅ Toggle OFF	Multiple selections
Radio Buttons	❌ Single only	✅ Toggle OFF	3–5 visible options
Record Choice Set	❌ Single only	✅ Toggle OFF	Records as dropdown (200 limit)

✅❌ Best Practices

🔥Always add "-- None --" as first Choice with empty value — signals field is optional to user
✅Use "Picklist from Object Field" option — auto-pulls active picklist values, stays in sync with org
✅Handle null output with Decision element: {!SelectedValue} IS NULL? → apply default logic
❌Multi-select picklist output = semicolon-separated string — need Apex to parse if further processing required

🎤 One-Line Answer for Interview

"Create a non-mandatory dropdown by adding a Picklist component to a Screen element, toggling the Required property OFF, adding a blank None choice as first option — then handling the potentially null output downstream with a Decision element to apply default logic when user skips the field."

Question 34

How to create a Two-Column Layout in Screen Flow?

✅ Answer

Drag the Section component onto the Screen canvas, set "Number of Columns" to 2 in properties, then drag any components into each column. Multiple Sections per Screen supported — mix layouts! 📐

📋 Section Component Key Facts

Property	Detail
Where to find	Screen Element → Components → Display → Section
Column options	1 Column / 2 Columns / 3 Columns
Multiple Sections per Screen	✅ Yes — mix and match column layouts
Responsive behavior	✅ Auto-collapses to single column on mobile
Custom column widths (30/70)?	❌ No — equal widths only — need Custom LWC
Code needed?	❌ No — pure declarative

✅❌ Section vs Custom LWC

✅Use Section component for standard equal-width columns — zero code needed
✅Mix layouts: 2-column section + 1-column notes section on same Screen
❌Cannot set custom column widths (e.g. 30/70 split) — always equal — need Custom LWC for that
✅Section label is optional — leave blank for seamless no-heading layout

🎤 One-Line Answer for Interview

"Create a two-column layout using the Section component — drag it onto Screen canvas, set Number of Columns to 2, then drag components into each column — with multiple Sections per Screen supported for mixing layouts, and Custom LWC needed only for custom column widths."

Question 35

Account Type changes to Open / Pending / Closed — capture date in Payment Date. How to build this Flow?

✅ Record-Triggered Before Save Flow

Build a Record-Triggered Before Save Flow on Account. Entry condition: {!$Record.Type__c} ≠ {!$Record__Prior.Type__c}. Assignment sets {!$Record.Payment_Date__c} = {!$Flow.CurrentDate}. Zero extra DML! ⚡

📋 Complete Solution Design

Step	Config	Why
Flow Type	Record-Triggered — Before Save	Updating SAME record — zero extra DML
Object	Account	Type field lives on Account
Trigger	Created or Updated	Type can also be set on creation
Entry Condition	{!$Record.Type__c} ≠ {!$Record__Prior.Type__c}	Fire ONLY when Type actually changes
Assignment	{!$Record.Payment_Date__c} = {!$Flow.CurrentDate}	Stamp today's date — Before Save = zero DML

✅❌ Optimized Version

🔥If ALL three Type values set the same thing — skip Decision → use single Assignment directly
🔥Use {!$Flow.CurrentDate} — NOT TODAY() — that's Formula syntax, invalid in Flow Assignment
✅If different dates per Type value → add Decision branching to different Assignments per value
✅Add Default outcome on Decision — handles future picklist values without runtime error
✅Use {!$Flow.CurrentDateTime} if Payment_Date__c is a DateTime field instead of Date

🎤 One-Line Answer for Interview

"Build a Record-Triggered Before Save Flow on Account — entry condition: Type__c not equal to prior Type__c — followed by an Assignment setting Payment_Date__c to {!$Flow.CurrentDate} — using Before Save's zero-DML direct record assignment for maximum performance and no recursion risk."

Question 36

How to create a Dependent Picklist in Screen Flow?

✅ Answer

Three approaches: Conditional Visibility (declarative, easiest), Two-Screen + Get Records (dynamic records), or Custom LWC (best UX — same-screen real-time updates). 🔗

📋 Methods Comparison

Method	Code?	Same Screen?	Dynamic Records?	Best For
Conditional Visibility	❌ No	✅ Yes	❌ Static values only	Small fixed value sets
Two Screens + Get Records	❌ No	❌ Two screens needed	✅ Yes	Record-based dependencies
Custom LWC	✅ Yes	✅ Yes	✅ Yes	Complex, large datasets, best UX
Native Object Field	❌ No	✅ Yes	✅ Auto from org config	Existing org field dependency

✅❌ Key Points

✅Conditional Visibility — separate picklist per parent value shown/hidden based on parent selection — zero code
✅Native object field — if dependency configured in Object Manager — Salesforce handles it automatically
🔥Custom LWC — reset child when parent changes: fire FlowAttributeChangeEvent('childField', '')
✅Disable child until parent selected: disabled={isChildDisabled} — prevents invalid state

🎤 One-Line Answer for Interview

"Dependent Picklists in Screen Flow can be built using Conditional Visibility to show/hide child picklists per parent value, using two screens with Get Records between them for record-based dependencies, or a Custom LWC with FlowAttributeChangeEvent that calls Apex for same-screen real-time dynamic child options."

Question 37

What are the Benefits of using Flow over Apex?

✅ Answer

Flow offers major advantages: no code, no test classes, no deployment complexity, Admin-maintainable, visual debugging, built-in versioning, instant rollback — making it Salesforce's officially recommended first choice. ⚡

📋 Flow vs Apex — Benefits Comparison

Benefit	Flow	Apex
Code required	❌ No	✅ Yes
Test class required	❌ No	✅ Mandatory (75%+ coverage)
Deployment needed	❌ Activate in UI	✅ Change Set / SFDX / DevOps
Who can build/maintain	Admin + Developer	Developer only
Business team can modify?	✅ Admin can change	❌ Developer bottleneck
Visual debugging	✅ Step-by-step canvas with variable values	❌ Debug logs only (hard to read)
Built-in version control	✅ Every save = new version	Requires Git / SFDX setup
Rollback speed	✅ Activate old version — 30 seconds	❌ Redeploy needed
UI capability	✅ Screen Flow — built in	❌ Needs separate VF/LWC

🌍 Real World Example — XYZ Company

At XYZ Company, Freight Charge Automation in Apex = 3 days dev + test + deployment window. Same logic in Flow = 2 hours → activated same day. Admin now maintains territory/freight rules independently — no developer bottleneck. Flow saved 2 days of development + deployment complexity.

🎤 One-Line Answer for Interview

"Flow advantages over Apex include no code or test class, instant activation without deployment, Admin maintainability for business agility, visual step-by-step debugging, built-in version control with instant rollback, and built-in Screen UI — making it Salesforce's officially recommended first choice with the 'Flow First, Apex Second' principle."

Question 38

What are the Advantages of Apex over Flow?

✅ Answer

While Flow-first is the recommendation, Apex is genuinely superior for bulk processing, dynamic SOQL, HTTP callouts, transaction control, complex algorithms — scenarios Flow simply cannot handle declaratively. 💪

📋 When Apex Wins Over Flow

Scenario	Why Apex Wins
Process 10,000+ records	Batch Apex chunks 200 records — Flow hits CPU limits
Dynamic SOQL at runtime	Object, fields, WHERE clause built dynamically — impossible in Flow
Native HTTP Callouts	Apex native — Flow needs Apex wrapper for callouts
Partial transaction rollback	Savepoints — Flow is all-or-nothing
Hourly / custom scheduling	Cron expressions — Flow only Daily/Weekly/Once
Complex JSON parsing	Full JSON deserialize class — Flow cannot parse JSON natively
Recursion / algorithms	Recursive methods — Flow cannot recurse
Automated CI/CD testing	Test classes with assertions — Flow debug is manual only

🌍 Real World Example — XYZ Company

At XYZ Company: Multi-Currency Conversion for 25,000 Orders → Flow attempted → CPU limit at ~2,000 records → switched to Queueable Apex chain. IndiaMART BC Integration → Apex handles HTTP callout, OAuth token refresh, nested JSON parsing — Flow simply cannot do any of this natively.

🎤 One-Line Answer for Interview

"Apex has significant advantages for bulk processing via Batch Apex, dynamic SOQL, native HTTP callouts, partial rollback using Savepoints, complex JSON parsing, recursive algorithms, hourly custom scheduling, and enterprise CI/CD testing — making it the right choice when Flow hits its declarative limits."

Question 39

What are the Best Practices for Salesforce Flow?

✅ Answer

Flow best practices ensure automations are performant, maintainable, secure, and scalable — avoiding governor limit errors, infinite loops, data corruption, and silent failures in production. 🏆

📋 Best Practices by Category

#	Category	Best Practice
1	Performance	NEVER do DML inside a Loop — collect → one bulk DML after
2	Performance	Use Entry Conditions with $Record__Prior — fire only on specific field changes
3	Performance	Before Save for same-record updates — zero extra DML
4	Performance	Get Records outside Loops — one SOQL, not one per iteration
5	Performance	Use Async Path for callouts and heavy external operations
6	Error Handling	Always add Fault Path on DML elements and Apex Actions
7	Error Handling	Log errors to custom Flow_Error_Log__c object
8	Error Handling	Handle null from Get Records with Decision element
9	Design	One Flow per process — separation of concerns
10	Design	Use Subflows for reusable logic — DRY principle
11	Design	Trigger Order with gaps of 10 (10, 20, 30)
12	Security	Choose correct running context per Flow type
13	Testing	Always debug as end user (not just Admin) before activating
14	Naming	Consistent naming: Object_Purpose_FlowType
15	Naming	Meaningful Interview Label for traceability

🔑 Top 5 Must-Know for Interviewer

🔥Never DML inside Loop = single most important performance rule — say this first
🔥Entry Conditions with $Record__Prior = biggest optimization for Record-Triggered Flows
🔥Fault Path on EVERY DML + Apex Action = difference between graceful failure and production disaster
💡Before Save = zero DML for same-record updates — always preferred over After Save
💡Subflows for reusability — change child once, updates everywhere across all parent Flows

🎤 One-Line Answer for Interview

"Flow best practices include never DML inside loops, precise $Record__Prior entry conditions, Before Save for same-record updates, Fault Paths on every risky element with custom error logging, Subflows for reusable logic, Trigger Order with gaps of 10, correct running context for security, and always debug as end user before activation."

Question 40

How to avoid Recursion in Salesforce Flow?

✅ Answer

Recursion happens when a Flow triggers itself in an infinite loop. Prevent using: Before Save Flows, $Record__Prior Entry Conditions, Boolean flag fields, or Static Variables in Apex Invocable Methods. 🔄

📋 All Recursion Prevention Techniques

Technique	How It Works	Best For
Before Save Flow	Assignment only — zero extra DML — no re-trigger possible	Same-record field updates
$Record__Prior Entry Conditions	Fire only when specific field changes — not on every update	Most common scenario — use always
Boolean Flag Field	Custom checkbox checked after first run — Flow skips if already checked	One-time-per-record processing
Static Variable in Apex	Invocable Method tracks processed IDs in static Set per transaction	Complex multi-Flow + Apex scenarios
Check Output Field	Entry condition: output field = prior output field (not yet updated)	Prevents re-trigger after Flow updates field

✅❌ Detection & Prevention

🔥Before Save = recursion-proof by design — zero DML = no re-trigger possible — most elegant solution
🔥$Record__Prior entry conditions = primary declarative prevention — must mention this first
✅Detect recursion: look for "Maximum trigger depth exceeded" error + repeated FLOW_START in debug logs
❌Recursion can be cross-object — Flow A updates Record B → Flow B updates Record A → infinite loop

🌍 Real World Example — XYZ Company

At XYZ Company, the Order INR Conversion After Save Flow had no entry condition → updated INR_Amount__c → Order changed → Flow fired again → infinite loop → CPU limit exceeded on 500 Orders. Fix: Entry condition — {!$Record.Amount__c} ≠ {!$Record__Prior.Amount__c} AND {!$Record.INR_Amount__c} = {!$Record__Prior.INR_Amount__c}. Solved immediately.

🔑 Key Points for Interviewer

🔥Before Save = recursion-proof by design — always prefer for same-record updates
🔥$Record__Prior entry conditions = most important declarative recursion prevention tool
💡Static variable in Apex = most robust — works across combined Flow + Apex trigger scenarios
💡"Maximum trigger depth exceeded" = the error message to recognize recursion in production

🎤 One-Line Answer for Interview

"Recursion in Flow is best prevented using Before Save Flow for same-record updates (physically impossible to recurse), $Record__Prior entry conditions to fire only on specific field changes, a Boolean flag field to mark already-processed records, or a static variable in an Apex Invocable Method tracking processed record IDs within the same transaction."