Automation with Flow

Flow is a visual automation builder. You drag elements onto a canvas, connect them, and Salesforce runs them when something happens: a record is saved, a user clicks a button or a schedule fires. Salesforce has ended support for the older tools, Workflow Rules and Process Builder, and tells admins to build new automation in Flow. You may still meet them in old orgs.

In this tutorial you will build a record-triggered flow on the Brew & Bean data model. Prerequisite: the objects from *Data model: objects, fields and relationships* (Coffee Order with Status, Customer and Allow Activities enabled).

Record-triggered flows run before save or after save. A before-save flow changes fields on the record that started it, before it is written to the database. It is very fast, so use it to set or clean fields on the same record. An after-save flow runs once the record exists, so it can create or update other records, send emails and call actions.

Data lives in variables (single values or records) and collections (lists of records). The record that triggered the flow is available as $Record. For an update, $Record__Prior holds the old values.

Goal: when a Coffee Order's Status changes to Ready, create a Task reminding someone to call the customer. Tasks are Salesforce's built-in to-do records. We enabled Allow Activities on Coffee Order so a Task can point to it.

Fields marked with the curly braces, like {!$Record.Id}, are Flow merge syntax: a reference to a value in the flow. In the builder you pick them from a list rather than typing.

Real flows need guards. Add a Decision when the flow should take different paths. For example, only create the task when a customer is present: a decision Has customer? with the outcome rule {!$Record.Customer__c} Is Null false.

Elements that change data can fail (a required field is missing, a validation rule blocks the save). Connect each such element's Fault path to a step that handles it, for example sending an email to the admin. Without this, users see an unhelpful error and nobody knows why.

To set a default on the same record, use a before-save flow. For instance: when a Coffee Order is created with no Status, set Status to Received.

1. New Record-Triggered Flow, object Coffee Order, trigger A record is created, optimise for Fast Field Updates. 2. Add an entry condition: Status__c Is Null true. 3. Add an Assignment: set {!$Record.Status__c} Equals Received. No Update Records element is needed, since the change is saved with the record.

In production you might also do this with a default value on the field, which is even simpler. Prefer the simplest option that works.

If your flow is a huge tangle of decisions, needs complex maths, or must process very large data volumes, move that logic to Apex. Triggers are covered in *Apex triggers and governor limits*. Many teams use a hybrid: Flow for the process, Apex for the hard part, called from a Flow action.

How this comes up in interviews. Typical questions: "Types of flows?", "Before-save versus after-save?", "What replaced Process Builder?", "How do you avoid hitting governor limits in a flow?" (no data operations in loops) and "How do you debug a flow?" (the Debug button, Run History and fault emails).

I'm an admin building a Salesforce Flow for this requirement: [describe in one or two sentences].

Objects and fields involved: [list with API names].

Give me: (1) which flow type to use and whether before-save or after-save, (2) the entry conditions, (3) the elements in order, (4) what could go wrong and where to add fault paths, (5) whether Apex would be better and why. Use plain language.

What to expect: Check the plan uses precise entry conditions, does not do data operations inside loops, and mentions fault handling. Build it in a sandbox or developer org first.