Loading tutorials…
Loading tutorials…
Salesforce automation has had three eras: Workflow Rules, Process Builder, and now Flow Builder. As of 2026, Workflow Rules and Process Builder are being retired — Flow Builder is the only path forward. Most owners are still building Process Builders that will break in 12 months. Here is the discipline.
Who this is forRevOps owners, sales admins, and founders building automation in their Salesforce org — or anyone inheriting an org with 40+ Workflow Rules and 20+ Process Builders that need to be migrated. If you have ever asked 'where is this automation actually firing from?' this tutorial is for you.
What you'll need
Step 1
Salesforce retired Process Builder in 2023 and is retiring Workflow Rules in 2026-2027. Both are sunset. Flow Builder is the only supported automation tool going forward.
Workflow Rules (released 2007) — declarative if/then automation. Limited to field updates, tasks, email alerts, outbound messages. Retired but still works in existing orgs.
Process Builder (released 2015) — successor to Workflow Rules with richer logic but slow runtime and known race conditions. Retired in 2023; existing Process Builders still run but cannot be created new.
Flow Builder (current standard) — modern visual automation tool with full Apex-equivalent capability: record-triggered flows, screen flows for user input, scheduled flows, platform-event flows. Performant, debuggable, version-controlled.
Salesforce ships a Migrate to Flow tool (Setup → Quick Find → "Migrate to Flow") that auto-converts Workflow Rules and Process Builders to equivalent Flows. Run this for every existing automation before the 2027 sunset.
Rule: never build new Workflow Rules. Never build new Process Builders. Every new automation goes in Flow Builder. Migrate existing automation as a Q1/Q2 project.
Step 2
Setup → Process Automation → Flows → New Flow. Flow Builder offers 6 flow types — pick wrong and you rebuild later.
Record-Triggered Flow: fires when a record is created, updated, or deleted. Replaces Workflow Rules and most Process Builders. Configure: which object, which trigger (Create / Create or Update / Update / Delete), which conditions, fast field updates vs full Flow.
Schedule-Triggered Flow: fires on a schedule (hourly, daily, weekly) against a filtered record set. Replaces Scheduled Apex for most use cases. Configure: schedule, object, filter.
Screen Flow: shows a multi-step UI to a user (custom wizards, guided processes). Used for Quick Actions, embedded in Lightning pages, or as standalone URLs. Replaces Visualforce wizards.
Platform Event-Triggered Flow: fires on a platform event (custom event, change data capture). For event-driven integrations.
Autolaunched Flow (No Trigger): callable from Apex, REST API, Process Builder (legacy), or other Flows. Reusable subprocess.
For 80% of automation needs, you want a Record-Triggered Flow. Start there.
Step 3
Setup → Process Automation → Flows → New Flow → Record-Triggered Flow. Define entry conditions strictly to prevent firing on unrelated saves.
Setup → Quick Find → "Flows" → New Flow → Record-Triggered Flow → choose object (e.g., Lead).
Configure Trigger: "A record is created or updated." Set Entry Conditions: only run when specific fields change. Example: Lead Status = "MQL" AND Lead Source != null. This prevents the Flow from running on every Lead save.
Choose Optimize the Flow for: Fast Field Updates (Before Save — quick, same-record only) OR Actions and Related Records (After Save — slower, can update related records and call actions).
Add the logic: Decision elements for branching, Get Records to query related data, Update Records to change other records, Create Records for new records, Action elements for email alerts / Apex / external callouts.
Set Fault Paths: every external action should have a fault path that logs the error. Without fault paths, failures are silent.
Activate the Flow only after testing in a sandbox or a Debug run (top-right Debug button in Flow Builder).
Step 4
Screen Flows are how you build custom wizards inside Salesforce. New Flow → Screen Flow. Add Screen elements, decision elements, and finish with a record action.
Setup → Quick Find → "Flows" → New Flow → Screen Flow.
Add a Screen element. Drag form components (Text, Picklist, Date, Long Text Area, Lookup) onto the screen. Set field labels, validation, and required flags.
Add Decision elements to branch the wizard based on user input. Example: 'If Inquiry Type = Demo Request, show Demo Scheduling screen; if Support, route to Case creation.'
End the flow with a Record Action (Create Records, Update Records) to persist the user input.
Expose the Screen Flow: Setup → Quick Action on an object → New Action → Action Type: Flow → pick your Flow. Or add to a Lightning Page via Lightning App Builder → drag the Flow component onto the page.
Test the user experience as the target user (Setup → Login as a User, available in some editions). Wizards that work for admins often confuse end users.
Step 5
Schedule-Triggered Flows handle recurring jobs: stuck-deal audits, lead-aging reports, inactive account flags. Setup → Flow → Schedule-Triggered Flow.
Setup → Flows → New Flow → Schedule-Triggered Flow.
Set the Schedule: Start Date, Frequency (Once, Daily, Weekly), Time of Day. For pipeline hygiene, daily at 6 AM is common.
Set the Object + Filter: which records to operate on each run. Example: Object = Opportunity, Filter = StageName = "Proposal Sent" AND LastModifiedDate < 30 days ago.
Build the logic: typically a loop through the filtered records performing an update or sending an alert. Example: set a custom field "Pipeline Health Flag" to "Stale" on every matching Opportunity, then email the Owner.
Activate. Salesforce will run the Flow on schedule. Monitor in Setup → Flows → click the Flow → Schedule Triggers → see successful runs and failures.
Limit: scheduled Flows have governor limits (50,000 record updates per run on most editions). For larger jobs, batch via Apex or break into chunks.
Step 6
Never edit Flows directly in production. Build in a sandbox, debug, deploy via Change Set or DX. Production drift is the #1 reason orgs become unmaintainable.
Sandbox: Setup → Sandboxes → New Sandbox. Use a Developer or Partial Copy sandbox for Flow development. Refresh monthly.
Build in sandbox. Test with realistic data. Use the Debug feature (top-right of Flow Builder) — pick a sample record, walk through every decision and action, verify the outcome.
Deploy: Setup → Outbound Change Sets (Sandbox) → New Change Set → add the Flow → upload to production. In production: Setup → Inbound Change Sets → Deploy.
Better: use Salesforce DX + version control. Every Flow is a metadata file (.flow-meta.xml) that lives in a Git repo. Code review every change. Use sfdx force:source:deploy for repeatable deploys.
Document every Flow: name, purpose, trigger conditions, side effects, owner. Future-you in 18 months will not remember what 'Flow_Auto_Update_Lead_Status_v3' actually does.
Step 7
Setup → Process Automation → Migrate to Flow. Salesforce auto-converts legacy automation to equivalent Flows. Audit each carefully — auto-conversion is not perfect.
Setup → Quick Find → "Migrate to Flow."
The tool lists every Workflow Rule and Process Builder in your org. Pick one to convert. The tool generates a new (inactive) Flow with the equivalent logic.
Review the generated Flow carefully. Common issues: time-based triggers in Workflow Rules become Scheduled Paths in Flows (good), but field references sometimes break if the original Rule used Old Value / New Value comparisons (needs manual fix).
Test the new Flow in a sandbox alongside the old Workflow Rule running in parallel. Confirm both produce identical outcomes for a representative sample.
Activate the new Flow. Deactivate the old Workflow Rule. Wait 7-14 days monitoring for issues. Then delete the old Workflow Rule.
Plan for 1-2 hours per simple Workflow Rule and 4-8 hours per complex Process Builder. A 40-rule org is a 2-3 month migration project — start in 2026 to beat the sunset.
Common mistakes
Building new Workflow Rules or Process Builders in 2026
What goes wrong: Every new Workflow Rule or Process Builder will need to be re-built in Flow before the 2027 sunset. Doubling your migration work. Plus, both tools have known race conditions that produce intermittently wrong data — rep adoption drops because reports do not match Opportunity records.
How to avoid: Never build new Workflow Rules or Process Builders. Every new automation goes in Flow Builder. Setup → Process Automation → Flows → New Flow.
No entry conditions on Record-Triggered Flows
What goes wrong: Flow fires on every Lead save — including when a rep edits a Phone Number that has nothing to do with the automation logic. Performance degrades, governor limits trip, automation runs 1,000x more than needed. Org performance drops noticeably.
How to avoid: Always set Entry Conditions on Record-Triggered Flows. "Only run when specific fields change" → list the actual fields. Restrict the Flow to firing only on the saves that matter.
Building automation without fault paths
What goes wrong: External callouts fail silently. A Flow tries to update a related record that does not exist. The Flow errors and the user sees a generic Salesforce error — but nothing is logged. Reports show a 30% revenue gap because critical updates never landed and nobody noticed for weeks.
How to avoid: Every Action, Update Records, and Create Records element should have a Fault Path. Route faults to a Log Custom Object record or an email to the admin. Visibility on failures is non-negotiable.
Editing Flows directly in production
What goes wrong: An admin edits a critical Flow in production at 4 PM Friday. The change breaks Lead routing for 2 days. Sales loses 40 leads over the weekend that never got assigned. Rep adoption drops to 20% the following month because reps stop trusting that automation runs reliably.
How to avoid: Build in sandbox. Test with Debug. Deploy via Change Set or DX. Never edit production Flows directly except for emergency hotfixes.
No documentation on Flows
What goes wrong: You leave the company / hand off the org. The next admin opens Flow Builder and sees 60 Flows with cryptic names like 'Flow_3' and 'New Lead Process v7.' Six months of reverse-engineering before they can confidently modify anything.
How to avoid: Document every Flow: descriptive name, Description field filled in, owner, last review date. Maintain a Flow inventory in a Google Doc or Notion outside Salesforce.
Stacking Flows + Process Builders + Workflow Rules on the same object
What goes wrong: Lead object has 8 Workflow Rules, 4 Process Builders, and 5 Flows all firing on save. Order of execution is unpredictable. Some automations race against each other. Reports show inconsistent data — 'sometimes this field updates, sometimes it does not.' Rep adoption tanks because the data is untrustworthy.
How to avoid: Migrate all Workflow Rules and Process Builders to Flow. Consolidate to 1-2 Record-Triggered Flows per object with clear decision branches. Use the Flow Trigger Explorer (Setup → Flow Trigger Explorer) to see all triggers per object.
Recap
Done — what's next
How to set up Salesforce lead routing that actually gets leads worked
Read the next tutorial
Hand it off
Salesforce automation is a real engineering discipline — race conditions, governor limits, fault handling, deployment hygiene. DIY-built automation in 2026 carries 2027 sunset risk. A specialist who has built and migrated 50+ automation libraries will save you the rebuild. EverestX Salesforce-capable specialists run $400-1,200/mo at $14-16/hr for ongoing automation work, or $400-800 for a one-shot Workflow-to-Flow migration.
See specialist rates
Salesforce announced Workflow Rules will be retired alongside Process Builder. Process Builder was retired for new builds in 2023. Workflow Rules' formal end-of-life is targeted for 2027 in most editions. Existing Workflow Rules will continue to run until then, but no new ones can be created in newer orgs. Plan a migration project for late 2026.
For 90%+ of automation needs, yes. Flow Builder handles record CRUD, decisions, loops, external callouts, scheduled jobs, and platform events. Apex is still needed for complex algorithms, certain bulk operations beyond Flow's governor limits, custom REST APIs, and triggers with intricate business logic. Most B2B teams under 50 reps never write Apex.
Setup → Flow Trigger Explorer shows all automation that fires on a given object's save event, in order. Use this to audit and consolidate. Debug Logs (Setup → Debug Logs) also show every automation that fires per transaction, useful for diagnosing race conditions.
Yes — via Salesforce DX. Flows are stored as metadata XML files (.flow-meta.xml). Use sfdx force:source:retrieve to pull them into a Git repo. Code-review changes. Deploy via sfdx force:source:deploy or in a CI/CD pipeline. This is now the standard for any team with 2+ admins.
The Flow throws an unhandled exception, the transaction rolls back, and the user sees a Salesforce error. Common limits: 100 SOQL queries per transaction, 150 DML statements, 50,000 records per query. For bulk operations, use bulk-safe patterns (Get Records once, loop in memory, Update Records once with the collection) — not Get/Update inside a loop.
Salesforce
Lead routing is where most Salesforce orgs leak revenue silently. A Lead lands at 2 PM, sits unassigned until Wednesday, and the prospect has booked a call with your competitor by Thursday. Here is the routing discipline that turns leads into meetings within 5 minutes.
Salesforce
Salesforce data quality decays silently. Duplicates compound, validation gaps widen, sync drift accumulates. By the time leadership notices, reports are 30% wrong and rep adoption has tanked. Here is the systematic diagnosis + fix sequence.
Salesforce
Salesforce ships 200+ stock reports nobody opens. The reports leadership actually trusts are built deliberately — right Report Type, right filters, right summary formulas, right dashboard layout. Here is the discipline that gets reports onto the CRO's Monday review.
HubSpot Marketing Hub
Workflows are the engine under HubSpot's marketing automation. They are also where 80% of the silent breakage happens — wrong enrollment criteria, missing re-enrollment toggles, branch logic that loops. Here's how specialists build them so they hold up.
Salesforce
DIY Salesforce admin is a great idea — until it is not. This is the honest framework: when the cost of self-managing exceeds the cost of hiring, and how to tell which side you are on.