Salesforce Flow – Overview & Key Concepts

Salesforce Flow is Salesforce’s main declarative automation tool. It lets you build complex business processes (create/update records, send emails, call Apex, show screens, run in the background or on a schedule) without writing code. It is the recommended replacement for Workflow Rules and Process Builder.

---

Types of Flows

1. Record-Triggered Flow

   • Runs when a record is created, updated, or deleted.

   • Used for most automation: field updates, creating related records, sending emails, etc.

   • Can run before-save (best for fast field updates on the same record) or after-save (for related records, emails, subflows, Apex).

2. Screen Flow

   • Provides a guided UI for users with screens, fields, and choices.

   • Used for wizards, guided case handling, data entry, or complex user processes on Lightning pages and quick actions.

3. Schedule-Triggered Flow

   • Runs on a schedule (e.g., nightly, weekly).

   • Used for batch processes like clean-up, reminders, updating stale records, or periodic checks.

4. Autolaunched Flow

   • Has no direct UI or trigger by itself.

   • Called from other flows, Apex, buttons, or processes to reuse logic.

---

Key Flow Concepts

• Elements (the building blocks of a flow):

  • Data: Get Records, Create Records, Update Records, Delete Records

  • Logic: Decision (IF/ELSE), Assignment, Loop, Subflow

  • Interaction: Screen (in Screen Flows), Actions (send email, Apex, quick actions)

• Resources (data holders inside a flow):

  • Variables, Collections, Constants, Formulas, Text Templates.

• Connectors:

  • The arrows that define the path between elements and control the flow of logic.

---

Before-Save vs After-Save (Record-Triggered)

• Before-Save

  • Runs before the record is committed to the database.

  • Ideal for simple field updates on the same record.

  • More efficient (no extra DML).

• After-Save

  • Runs after the record is saved.

  • Used when you need the record Id, work with related records, send emails, call subflows/Apex, etc.

---

Flow vs Workflow Rules vs Process Builder

• Workflow Rules – Old and limited (field updates, email alerts, tasks, outbound messages).

• Process Builder – More powerful than Workflow, but slower and being phased out.

• Flow – Most powerful and flexible, supports complex branching, loops, screen UI, and better performance.

• Best practice now: Use Flows for all new automation and plan to migrate older Workflow/Process Builder logic into Flow over time.

---

Error Handling & Debugging

• Use Debug in Flow Builder to test flows with real data and see each step and variable value.

• Add Fault paths from data elements (Get/Create/Update/Delete) to catch errors. In a fault path you can:

  • Create an error log record.

  • Send an email to admins with the error message.

• Check Paused and Failed Flow Interviews and debug logs when troubleshooting.

---

Best Practices

• Use before-save flows for simple field updates (fast, efficient).

• Keep clear, consistent naming for flows, elements, variables (e.g., Opp_BeforeSave_Updates, Decision_IsClosedWon).

• Avoid SOQL/DML inside loops; use collections and then perform a single update.

• Reduce the number of flows per object; consolidate logic using Decision elements when possible.

• Document flows with descriptions and comments for future admins.

• Always test in a sandbox and use Debug before deployment.

• Consider bulk operations (imports, integrations) and build flows to handle multiple records.

---

Example Business Use Case (Ready to Say)

“For example, I built a record-triggered flow on Opportunity that runs after save. When an Opportunity is marked ‘Closed Won’, the flow automatically:

• Creates a related Onboarding/Project record,

• Updates the Account status to ‘Customer’,

• Sends an email notification to the onboarding team.
  This reduced manual work, ensured consistency, and improved handover from sales to delivery.”

---

1. What is Salesforce Flow and why is it used?

Answer:
Salesforce Flow is the main declarative automation tool in Salesforce. It lets you build complex business processes (create/update records, send emails, call Apex, show screens) without code, using a drag-and-drop Flow Builder. It’s now the recommended replacement for Workflow Rules and Process Builder.

2. What are the main types of Flows you’ve used?

Answer:
The main types I use are:

• Record-Triggered Flows – Run when a record is created, updated, or deleted. I use them for field updates, creating related records, sending emails, etc.

• Screen Flows – For guided UI wizards in Lightning pages or quick actions.

• Schedule-Triggered Flows – For batch jobs like nightly clean-ups or reminders.

• Autolaunched Flows – No direct trigger; I call them from other flows, Apex, or buttons for reusable logic.

3. Difference between “Before-Save” and “After-Save” Record-Triggered Flows?

Answer:

• Before-Save Flows:

  • Run before the record is saved.

  • Best for simple field updates on the same record.

  • Faster and more efficient because they avoid an extra DML.

• After-Save Flows:

  • Run after the record is saved.

  • Used when I need the record ID or to work with related records, send emails, or call subflows/Apex.

4. How do you decide between Flow vs Process Builder vs Workflow Rule?

Answer:
I follow Salesforce’s direction:

• New automation → I use Flow.

• Existing Process Builder/Workflow → I plan to migrate to Flow over time.

• Workflow Rules and Process Builder are kept only for legacy reasons; they’re limited and being phased out. Flow is more flexible, supports branching, loops, screen UI, and is better for performance.

5. Can you explain key Flow elements you use often?

Answer:

• Get Records – Query records from Salesforce.

• Create / Update / Delete Records – DML actions.

• Decision – IF/ELSE branching.

• Assignment – Set values in variables.

• Loop – Iterate through a collection of records.

• Subflow – Call another flow to reuse logic.

• Screen – Build UI for users in Screen Flows.

6. How do you handle errors in a Flow?

Answer:

• I always add Fault Paths from data elements (Get/Create/Update/Delete).

• In the fault path I might:

  • Create a log record in a custom object.

  • Send an email to admins with the error.

• I use the Debug tool in Flow Builder to test with sample records and see exactly where it fails before deploying.

7. Give an example of a business process you automated with Flow.

Answer (template you can adapt):

“I built a record-triggered flow on Opportunity that runs after save. When an Opportunity is marked as ‘Closed Won’, the flow automatically:

• Creates a related Project/Onboarding record.

• Updates the Account with the new ‘Customer’ status.

• Sends an email to the onboarding team with key Opportunity details.
  This removed manual steps and ensured nothing is missed when a deal closes.”

You can swap in Case, Lead, or any real example from your experience.

8. How do you avoid hitting limits or creating conflicting automation?

Answer:

• I try to keep as few record-triggered flows per object per context as possible (e.g., one before-save, one after-save).

• I combine related logic inside the same flow and use Decision elements instead of multiple flows.

• I avoid unnecessary SOQL/DML inside loops; I use collections and do bulk updates.

• I check for existing automation on the same object (old Workflow, Process Builder, other Flows) to avoid conflicts.

9. How do you debug a Flow that users say is “not working”?

Answer:

• First, I try to reproduce the scenario with the same user profile/record.

• Then I use Debug on Flow with the exact record values.

• I check:

  • Are entry conditions correct?

  • Are Decision criteria matching?

  • Any errors on the fault paths?

• I also check Setup → Paused and Failed Flow Interviews and Debug Logs for more details if needed.

10. What are some best practices you follow when building Flows?

Answer:

• Use clear naming for flows, elements, and variables (RTF_Opportunity_BeforeSave, Decision_IsClosedWon).

• Add descriptions and comments for maintainability.

• Use before-save flows for simple field updates.

• Always add fault paths to catch errors.

• Test in sandbox with different data sets and profiles.

• Think bulk-safe: design flows to handle multiple records (e.g., from imports or integrations).