Salesforce Flow

Flow (or Salesforce Flow) is Salesforce's main declarative automation tool: a visual editor where you build a business process by connecting blocks on a canvas instead of programming it line by line. With Flow you can create and update records, show guided screens to the user, send emails or notifications, call other systems and orchestrate conditional logic, all without writing code.

The core idea is that much of what a company needs to automate (assigning a case, calculating a discount, triggering a follow-up when an opportunity changes stage) can be modeled declaratively. When the logic goes beyond what the editor allows, Flow relies on Apex through invocable actions, combining the visual approach with code only where it is needed. It is one of the pieces an implementation team works with when building on the platform, part of the work covered by Salesforce Developers.

Flow is the standard Salesforce recommends for automation: it replaced Workflow Rules and Process Builder, which are on their way to retirement. Learning Flow is, in practice, learning the platform's modern automation engine.

Why Flow matters

In any Salesforce implementation, the difference between a CRM that "stores data" and one that actually works for the team lies in automation. Flow is what turns a field change into a chain of actions: when a sales rep marks an opportunity as "Closed Won", Flow can create the billing account, notify finance, generate the onboarding task and update the sales forecast, all in milliseconds and without human intervention. That orchestration, done declaratively, is what lets small teams scale processes without hiring developers for every rule.

The most widely used Flow types

Flow is not a single thing: there are several types depending on when and how they run. Knowing the difference avoids costly design mistakes.

• Record-Triggered Flow: runs when a record is created, updated or deleted. It is the workhorse of background automation (assignments, cross-validations, triggers to other systems). It can run before the save (before-save, extremely fast for modifying the record itself) or after it (after-save, for touching related records or calling external services).
• Screen Flow: shows interactive screens to the user, ideal for guiding step-by-step processes (a customer onboarding assistant, a service script, a quoting wizard). It can be embedded in Lightning pages, Experience Cloud sites (communities) or the mobile app.
• Schedule-Triggered Flow: runs on a set schedule over batches of records (for example, marking invoices as overdue every night).
• Platform Event-Triggered Flow and Autolaunched Flow: invoked by events or from other processes, useful for integrations and complex orchestrations.

A concrete example in Argentina

Think of a consumer goods distributor in Buenos Aires that sells to kiosks and convenience stores. When an order enters the system, a Record-Triggered Flow checks the customer's credit limit: if the order is within the limit, it approves it and triggers the proactive notification to the warehouse; if it exceeds the limit, it creates a task for the collections team and holds the shipment. All of this is built in the visual editor, in hours, without a single semicolon of code. Before, that same logic lived in the sales manager's head or in a spreadsheet; now it lives in the platform, auditable and consistent.

Flow vs Apex: when to use each

The most common question from people getting started is when Flow is enough and when you need code. The rule of thumb: declarative first, code when declarative falls short or does not perform.

In real projects, the usual approach is a hybrid model: Flow orchestrates the process and delegates heavy calculations or complex calls to Apex through invocable actions.

Common mistakes to avoid

• Putting record operations inside loops over many records: it hits Salesforce's governor limits and can break the transaction. Best practice is to process in bulk, not record by record.
• Stacking multiple Flows on the same object: having five Record-Triggered Flows on Opportunity makes it impossible to know the order of execution. It is better to consolidate the logic.
• Not using a sandbox: testing automations directly in production is playing with fire. All new logic is validated first in a sandbox.
• Ignoring error handling: a Flow without fault paths fails silently. You need to define what happens when something goes wrong.

In short

Flow is the backbone of no-code automation in Salesforce. Well designed, it multiplies the team's productivity and keeps processes consistent; poorly designed, it runs into the platform's limits. Mastering it is one of the most valuable skills for an admin or consultant who builds on Salesforce.