Salesforce Building Screen Flows and Automation Flows

Knowing what Flow Builder is sets the foundation. This topic goes deeper — showing you how Screen Flows guide users through multi-step processes and how Record-Triggered Flows automate background work without any user interaction. These two flow types cover the majority of real-world use cases in Salesforce orgs.

Building a Screen Flow

A Screen Flow displays a series of screens to a user — like filling out a multi-page form. You embed the finished flow on a Salesforce record page, an app page, or an Experience Cloud portal. When a user clicks the button that launches the flow, screens appear in sequence and the flow collects or displays information at each step.

A Practical Example: New Case Intake Flow

A support team wants a structured way to log new customer cases. Instead of opening a blank Case form, they want a guided wizard that asks the right questions in the right order. Here is what the flow looks like:

  [Screen 1] Customer Details
  Fields: Customer Name (text), Account (lookup), Priority (picklist)
         |
         ↓
  [Screen 2] Issue Description
  Fields: Subject (text), Detailed Description (text area)
         |
         ↓
  [Decision] Is Priority = "Critical"?
        /YES                   \NO
       ↓                        ↓
  [Screen 3a]              [Screen 3b]
  "Escalation Contact"     "Expected Resolution Time"
       |                        |
       └──────────┬─────────────┘
                  ↓
  [Create Records] Create Case record with all collected values
                  ↓
  [Screen 4] Confirmation: "Case #{CaseNumber} has been created."
                  |
                [END]

Screen Components

Each Screen element in a Screen Flow contains components — the input and display elements the user interacts with:

  • Text Input — a single-line text box
  • Long Text Area — a multi-line text box
  • Number Input — accepts only numeric values
  • Picklist — a drop-down selector
  • Checkbox — a true/false toggle
  • Lookup — search for and select a related Salesforce record
  • Display Text — show information to the user (no input)
  • Display Image — show an image on the screen

Validating Screen Inputs

Inside each screen component, you set Required to TRUE to make the field mandatory. You also add Validate Input conditions with custom error messages. Example: on a phone number field, validate that the length equals 10 digits. If not, the flow shows "Please enter a valid 10-digit phone number" and prevents the user from moving to the next screen.

Passing Data Between Screens

Each screen component stores its value in a Flow Variable. You reference that variable in later screens or in Create/Update Records elements. For example, the Account selected on Screen 1 is stored in a record variable, and the Case created later uses that variable to populate the AccountId field.

Building a Record-Triggered Automation Flow

A Record-Triggered Flow fires automatically when a record is created, updated, or deleted — no user interaction needed. This is the most common automation type for replacing Workflow Rules and Process Builder.

A Practical Example: Auto-Create Onboarding Task on Closed Won

When a salesperson marks an Opportunity as "Closed Won," the team wants Salesforce to automatically create a Task for the onboarding manager with a due date 3 days from now.

  TRIGGER: Opportunity record is Updated
  CONDITION: StageName changes to "Closed Won"
  TIMING: After Save

  Step 1: [Assignment]
  Set variable: DueDate = TODAY() + 3
  Set variable: TaskSubject = "Begin onboarding for: " + Opportunity.Name

  Step 2: [Create Records]
  Object: Task
  Subject: {TaskSubject}
  Due Date: {DueDate}
  Assigned To: Onboarding Manager User ID
  Related To (WhatId): Opportunity Record ID
  Status: Not Started
  Priority: High

  Step 3: [Action — Send Email]
  Template: "New Onboarding Task Created"
  Recipient: Onboarding Manager

Entry Conditions

When you configure a Record-Triggered Flow, you set Entry Conditions to control exactly when the flow runs. Options:

  • All records — runs for every record that triggers the event
  • Only when conditions are met — runs only if specific field values match your criteria
  • Only when a field changes to a specific value — the most precise option, avoids re-running when unrelated fields are edited

Always use the most specific entry condition possible. A flow that runs unnecessarily on every save wastes processing time and can cause governor limit issues on high-volume orgs.

Loops in Flows: Processing Multiple Records

Sometimes a flow needs to process a collection of records one by one. The Loop element handles this. Here is how a loop works in plain language:

  [Get Records] → Retrieve all open Cases older than 7 days
  (Returns a Collection of Case records)
         |
  [Loop] → For each Case in the collection:
         |
         +→ [Decision] Is Case.Priority = "High"?
              /YES                 \NO
             ↓                     ↓
    [Update Record]           [Update Record]
    Set Status = "Escalated"  Set Status = "Pending Review"
         |                         |
         └──────────┬──────────────┘
                    ↓
         [Back to Loop — next Case]
         |
  [Loop ends when all Cases are processed]

Subflows: Reusing Logic

When two different flows need the same logic — like "send a welcome email" — you build that logic once in a separate flow and call it using a Subflow element. This avoids duplicating the same steps in multiple places. When the logic changes, you update the one subflow and every parent flow that calls it benefits automatically.

Deploying and Activating a Flow

A flow only runs when it is Activated. While building and testing, the flow stays inactive. When you are ready:

  • Save the flow — creates a new version without affecting the active version.
  • Debug the flow — use the built-in debugger to run the flow with test data and trace each step.
  • Activate the flow — the new version becomes live; the old version is deactivated automatically.

Always test in a Sandbox org before activating in Production. Mistakes in automation can affect large numbers of records instantly.

Key Points

  • Screen Flows guide users through multi-step wizards embedded on pages or portals — collecting and displaying data at each step.
  • Record-Triggered Flows fire automatically when records are created, updated, or deleted — replacing Workflow Rules and Process Builder.
  • Entry Conditions on Record-Triggered Flows control exactly when the flow runs — always be as specific as possible.
  • Loop elements process collections of records one by one, enabling bulk automation logic.
  • Subflows let you reuse a block of logic across multiple flows without duplication.
Previous lessons
Back to courses
Next lessons

Leave a Comment