Learn Salesforce Flows: Screen, Record-Triggered and Scheduled Flows, Hands-On

To learn Salesforce Flows, start with screen flows to understand variables, elements and the data layer, then move to record-triggered flows (before-save and after-save), scheduled, autolaunched and platform-event-triggered flows. Finish with HTTP callouts and the Flow Trigger Explorer. That's the order the course above takes, and every flow is built live in a real org, including the ones that fail so you can see how to debug them.

What Flow is and where you use it

Flow is Salesforce's declarative automation tool. You build logic visually in Flow Builder with elements such as Get Records, Decision, Loop, Assignment, Create Records and Update Records, and Salesforce runs it as part of the transaction.

It has replaced Workflow Rules and Process Builder, so on any project today, Flow is where you'll build:

• Guided processes with screen flows: intake forms, case triage, onboarding wizards
• Field updates on save with before-save record-triggered flows
• Related-record automation with after-save flows: create a task, update a parent, send an email
• Time-based work with scheduled flows and scheduled paths
• Reusable subflows and autolaunched flows called from other flows, Apex or the API
• Event-driven automation that responds to platform events

Prerequisites

• The admin fundamentals. You need to understand objects, relationships, record types and the sharing model. The free admin course covers them.
• Formula comfort. Flow uses formula resources and conditions constantly.
• No code required. Basic programming ideas such as variables, loops and conditions help, and the course explains them as it goes.

What you'll be able to build afterwards

• Multi-screen flows with validation, dynamic choices and record lookups
• Record-triggered automation split correctly between before-save and after-save
• Scheduled flows that process batches of records each night
• Flows that call external REST APIs with the HTTP Callout action
• Flows that react to platform events
• A predictable order of execution for several flows on one object, using the Flow Trigger Explorer

A worked scenario: closing a won deal properly

Requirement: when an opportunity moves to Closed Won, stamp the date it was won, and open an onboarding case for the customer. A beginner builds this as one after-save flow. I build it as two, and here's why.

Flow 1: before-save, to stamp the date

1. Create a record-triggered flow on Opportunity. Trigger it when a record is created or updated, and optimise it for Fast Field Updates (before-save).
2. Set the entry condition: StageName equals Closed Won.
3. Under when to run the flow for updated records, choose only when a record is updated to meet the condition requirements. Without this, the flow runs on every edit of an already-won deal.
4. Add an Assignment element that sets $Record.Won_Date__c to $Flow.CurrentDate.

There's no Update Records element. In a before-save flow, changes to $Record are saved with the record itself, with no extra DML. That's why before-save is the fastest way to update fields on the triggering record.

Flow 2: after-save, to create the case

1. Create a second record-triggered flow on Opportunity with the same entry condition and the same "only when updated to meet the condition" setting, optimised for Actions and Related Records.
2. Add a Create Records element for a Case, with AccountId set to $Record.AccountId, a subject such as "Onboarding" and the right record type.
3. Add a fault path to the Create Records element that notifies an admin or logs the error. Otherwise, a failed insert rolls back the opportunity save and the user sees an unhelpful error.

Now test it with a data load of 200 opportunities, not just one. Because Create Records sits outside any loop, Flow bulkifies it across all the records in the transaction.

Common mistakes beginners make

1. Data elements inside loops. A Get Records, Create Records or Update Records inside a Loop runs once per iteration and hits governor limits. Collect records in a collection variable and do one DML after the loop.
2. Using after-save to update the triggering record. That's an extra DML and can re-fire automation. Use before-save for same-record field updates.
3. Missing entry conditions. A flow with no entry condition, or without "only when updated to meet the condition", runs on every save.
4. No fault paths. Every data element and action can fail. Handle the failure.
5. Hard-coded IDs for record types, queues or users. Look them up by developer name.
6. Many flows on one object with no plan. Set trigger order and check it in the Flow Trigger Explorer, and decide whether each object is flow-driven or trigger-driven.
7. Building on Workflow Rules or Process Builder. Migrate them to Flow instead.

How Flow connects to the other topics

• Flow builds on the data model and security from the Salesforce admin guide, and it's the core of the Salesforce admin roadmap.
• When a flow gets too complex, an invocable Apex action called from the flow is often the cleanest fix. The admin-to-developer roadmap starts right there.
• Screen flows can host custom Lightning Web Components.
• HTTP callouts and platform-event-triggered flows overlap with Salesforce integration.
• For interviews, practise Salesforce Flow interview questions. Order of execution and before-save versus after-save come up constantly.

Who should skip this

• Skip it if you already build record-triggered and scheduled flows with fault paths and bulk-safe designs. Look at the HTTP callout and platform-event modules only.
• Skip it if you're a developer on a team where every object is trigger-driven by policy. Even then, learn enough Flow to read what admins build.
• Don't skip it if you're an admin. Flow is the most valuable skill in the admin toolkit.

Want to check the teaching style first? The free admin course is taught the same way, so watch a few episodes before you subscribe. There are no refunds.