April 25, 2023
Automating a business process in Salesforce is no longer a question of which tool you pick. Flow is the answer, and the older tools most orgs were built on are on their way out. So the real work now is not building new automation. It is finding what you already have, deciding what still earns its place, and moving the rest without breaking production.
Here is the situation in most orgs. Someone built a workflow rule years ago to update a field. Someone else added a Process Builder process that touched the same record. A flow arrived last year doing something similar. Now a record save fires all three, in an order nobody chose. A small change to one produces a bug in another. The team stops touching automation because nobody is sure what will break.
This guide is about that reality. You will see where your existing automation is hiding and what it converts to. You will see how to pick the right flow for a job and why the order things run in matters. You will also see what not to automate, and how to sequence a migration that does not take the org down.
Salesforce has been moving customers onto Flow for years. Workflow Rules and Process Builder are the tools being retired. Salesforce ships a Migrate to Flow tool in Setup to help convert them.
The end-of-support date has moved more than once. Check the current one with Salesforce rather than a blog post, including this one. The direction is not in doubt. The deadline is.
What matters more than the date is the drift. Automation built across three tools over six years rarely has one owner or one logic. That is a maintenance problem whatever the support status.
Most teams underestimate how much is running. Before you migrate anything, list what fires and on which object.
| What you may have | Status | Where to find it in Setup | What it becomes |
|---|---|---|---|
| Workflow Rules | Being retired | Workflow Rules | A record-triggered flow |
| Process Builder processes | Being retired | Process Automation / Process Builder | A record-triggered flow |
| Flows | Current | Flows | Stays, but may need consolidating |
| Apex triggers | Current | Apex Triggers | Stays where code is genuinely needed |
| Approval processes | Current | Approval Processes | Stays, often called from a flow |
| Assignment and escalation rules | Current | Lead / Case Assignment Rules | Stays, but check it does not duplicate a flow |
| Validation rules | Current | Object Manager, per object | Stays, and runs before your automation |
| Email alerts and field updates | Tied to the old tools | Under the parent rule or process | Move into the replacing flow |
Work through that list object by object rather than tool by tool. A single object with four things firing on save is the problem worth solving first.
Flow is one name for several different tools. Picking the wrong one is the most common reason an automation is slow, fragile, or impossible to debug.
| Flow type | Fires when | Best for | Do not use it for |
|---|---|---|---|
| Record-triggered, before save | A record is saved, before it is written | Setting fields on the record being saved | Sending email, creating other records |
| Record-triggered, after save | A record is saved, after it is written | Creating or updating related records, sending email | Simple same-record field updates |
| Screen flow | A user launches it | Guided steps where a person makes choices | Anything that should run unattended |
| Scheduled-triggered | On a schedule you set | Nightly batches, expiry reminders, cleanup | Anything that must happen instantly |
| Platform event-triggered | An event message arrives | Reacting to another system’s signal | Ordinary record changes |
| Autolaunched | Called by other automation or Apex | Shared logic reused in several places | Anything needing a user interface |
The one that saves the most time is the before-save record-triggered flow. If all you are doing is setting a field on the record being saved, before-save does it without a second database write.
A single record save is not one event. Salesforce runs a sequence, and automation sits at several points inside it.
Validation rules run before most automation, so a flow cannot fix a value that validation has already rejected. Before-save automation runs next, then after-save automation, and roll-up summary fields recalculate later still.
That last part causes the confusing bugs. A roll-up recalculation can update a parent record, which can fire the parent's own automation, which can update the child again. Nobody wrote a loop, and yet the org behaves like there is one. Technical walkthroughs on Salesforce Codex are useful when you are tracing one of these.
The practical rule is to keep one automation per object per timing. Two after-save flows on the same object will fire in an order you do not control.
Salesforce runs your automation inside a shared platform. Every transaction has ceilings on queries, database operations, and processing time. Automation that works for one record can fail on a bulk load.
The usual causes are predictable. A flow that queries or updates inside a loop multiplies its work by the record count. A flow that calls another flow, which calls a third, stacks all of it into one transaction. A trigger and a flow doing similar work on the same object double the cost.
Test with a bulk load, not a single record. Import a realistic batch into a sandbox and watch what fails. Practitioner posts on SFDC Stop cover the debugging side of this well.
Automation is not free. Every rule is something to maintain, document, and explain to the next admin.
Skip it when the process changes often. Automating a rule that will be different next quarter costs more than doing it by hand. Skip it when the step needs judgment. A flow makes the same call every time, and the exceptions pile up as complaints.
Skip it too when the process is not written down. Automating a process nobody has agreed on just makes the disagreement faster and harder to see.
The honest version is that some manual steps are correct. A step that happens twice a month and takes five minutes is not a problem worth a flow.
Order matters more than speed here. Convert in this sequence and each stage is reversible.
Never convert several objects in one release. When something misbehaves you want one suspect, not six. Deep dives on Jitendra Zaa cover the platform internals behind several of these steps.
We start with an inventory rather than a conversion. Reading every rule, process, flow, and trigger by object tells us what is duplicated, what is dead, and what is load-bearing.
From there we produce a conversion order with a risk rating against each item. Anything we plan to retire gets a named business owner. Nothing gets switched off without a signature.
Our engineers then convert and test in waves. Bulk testing is part of each release, not a step at the end. Our guide to Salesforce automation tools covers the wider toolset if you are still mapping the landscape.
No. It converts the mechanics and gives you a working starting point. It does not consolidate overlapping logic or tell you what to retire, and those are the parts that take judgment.
Sometimes. Was the original rule a workaround for a process you have since changed? Rebuilding from the current requirement beats converting the old one faithfully.
Yes, and plenty of orgs run both. Keep the boundary deliberate, with one owning the record-level updates and the other owning anything that needs code.
Write down which object each automation belongs to and who owns it, and review the list each release. Our post on record-triggered flows for opportunity updates shows what a disciplined pattern looks like.
Those follow the same rules but have their own patterns. Our guide to automating sales and marketing in Salesforce covers that ground.
The automation question in a mature org is rarely what to build. It is what is already running, what it costs to keep, and what happens when two rules disagree. Start with an inventory by object. Keep one automation per object per timing. Test with a bulk load before anything reaches production.
Minuscule Technologies works on this from the engineering side. Our Accelerators cover the inventory and conversion passes. The audit does not start from a blank spreadsheet, and the migration follows a proven order. We also tell you plainly which rules should be retired rather than converted.
Is your org running automation nobody wants to touch? Bring it to Minuscule Technologies. We will inventory what fires on every object and hand you a conversion order with the risk marked on each item. Broader platform work sits in our Salesforce consulting services.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
