Flow is Salesforce's point-and-click automation builder: you drag in elements to get records, make decisions, update data, and show screens, then set the flow to run on a schedule, a record change, or a user action, with no code required. It's the current replacement for the older Workflow Rules and Process Builder tools, both of which Salesforce has been actively retiring in favor of Flow. Here's how it actually works, and where native Flow stops being enough.
1. Open Flow Builder. From Setup, search Flows under Process Automation and click New Flow. Salesforce gives you a short list of flow types to start from.
2. Pick the right flow type. A Screen Flow walks a user through a form with multiple steps, good for guided data entry. A Record-Triggered Flow runs automatically when a record is created, updated, or deleted, the modern replacement for most workflow rules. A Scheduled Flow runs on a time-based trigger, like checking every night for contracts expiring in 90 days.
3. Add elements to build the logic. Get Records pulls data in, Decision elements branch the logic based on conditions, Assignment elements set variable values, and Create Records/Update Records/Delete Records elements change data. For a screen flow, Screen elements collect input from whoever's running it.
4. Test it. Use Flow Builder's built-in debug mode to run through the logic with sample data before anyone else touches it. This catches most obvious errors, wrong field references, missing null checks, before they hit real records.
5. Activate it. A flow does nothing until you activate it. Once active, a record-triggered flow starts firing on every matching record change going forward, so double check the trigger conditions are exactly what you intend.
Flow is genuinely good at what it's built for: logic that stays inside Salesforce's own data and a handful of native actions, like posting to Chatter or sending an email. It starts to struggle the moment the automation needs to reach a system that isn't Salesforce. A basic REST callout to a well-behaved API is possible but awkward in pure Flow, and anything more complex, like handling an error response, retrying, or transforming a payload, usually needs an Apex class behind the scenes instead.
The harder gap shows up when the other system doesn't have a usable API at all. A lot of the tools businesses actually run alongside Salesforce, an older vendor portal, a carrier's tracking site, an internal tool nobody wants to touch, simply don't expose the data or the action through an API. Flow has no answer for that. It can't click a button on someone else's website for you.
That's a real limit, not a Salesforce failure: the tool on the other end just doesn't offer an API. The fix isn't to wait for one. It's to automate the same action a person would take, through the actual interface, using headless-browser automation that drives that other system the way a human would, then feeds the result back into the flow.
When a flow needs to talk to an external system with real error handling, retries, or data transformation, we build the Apex class or middleware service behind it so the flow itself stays simple.
For the vendor portals, carrier sites, and internal tools that never shipped an API, we build headless-browser automation that performs the action directly in that system's interface, then reports the result back into Salesforce so your flow can act on it.
Tell us the step that still needs a human because the other system won't cooperate. We'll tell you whether that's an Apex callout, a middleware piece, or something that needs browser-level automation to get unstuck.
If your flow runs fine until it needs another system to cooperate, that's usually a missing API problem, not a Flow problem, and it's solvable either way. Salesforce automation is just one piece of what we build; we connect and automate whatever's manual across your business, Salesforce or not.
Let's talk →They're three generations of the same idea. Workflow Rules are the oldest and most limited, mainly field updates and simple email alerts. Process Builder, built later, could do more (related record updates, invoking other processes) but ran into performance and complexity problems at scale. Flow is the current tool and the one Salesforce has been steering everyone toward, since it can do everything the older two could plus far more, including screens, loops, and subflows.
Salesforce has been winding both down in favor of Flow, including blocking new Workflow Rules and Process Builder creation on newer orgs and offering a Migrate to Flow tool for existing ones. If you still have either running, it's worth planning the move to Flow rather than building anything new on the older tools.
Yes, through an HTTP Callout action, though for anything beyond a simple request you'll typically wrap the callout in an Apex class that the flow invokes, since Apex gives you proper error handling and response parsing that raw Flow elements don't.
A validation rule stops a record from saving unless a condition you define is met, for example requiring a close date before an opportunity can move to Closed Won. It runs at save time, which makes it a different tool than Flow: validation rules block bad data, flows automate what happens after good data is already there.
A screen flow is interactive: a user runs it and steps through a form. A record-triggered flow runs automatically in the background whenever a record is created, updated, or deleted, with no user interaction at all.