Naming conventions are an often-overlooked part of building on Salesforce, especially for API names. It can seem irrelevant: who cares what things are called behind the scenes? Only the admin and the Salesforce team see it, and figuring out how things work is their job.
But consistent naming gives you a back end that is easier to understand, work in, and navigate over time. The team working in your Salesforce org today won't be the team working in it years from now. Firm naming standards make the org understandable to anyone, and make it obvious which pieces belong to which process. That is a big part of what lets a business run and change its own Salesforce, instead of depending on whoever built it.
You gave the flow what name?
Flow has become the workhorse of Salesforce, and you will end up with a lot of flows whether you plan to or not. Imagine several automations on the Task object, which has several record types. Someone builds flows with names like "Update Task Due Date on Sales Task", "Set Task Owner at Creation", and "Complete Task Screen". Some of them apply only to one record type.
Then a new requirement arrives: more automation on Task, for one record type. How do you quickly see which flows already exist for that object and record type? How do you decide whether to build a new flow or add logic to an existing one? Without a naming convention, and often without a flow automation strategy, there's no quick way to know.
Rename those flows with a standard pattern:
- "Update Task Due Date" becomes
Task [BS] - Sales Task - Handler - "Set Task Owner at Creation" becomes
Task [BS] - All Record Types - Set Owner - "Complete Task Screen" becomes
Task [SCR] - Complete Task
Now you can build a list view per object and see every flow at a glance. Here is what a Task list view looks like once everything follows the pattern:
| Flow label | Process type | Trigger |
|---|---|---|
| Task [AL] - Related Case Notifications | Autolaunched Flow | - |
| Task [AS] - Next Step - Handler | Autolaunched Flow | Record - Run After Save |
| Task [BS] - Handler | Autolaunched Flow | Record - Run Before Save |
| Task [BS] - Next Step - Handler | Autolaunched Flow | Record - Run Before Save |
| Task [SCR] - Create Task | Screen Flow | - |
| Task [SCR] - Next Step Detail | Screen Flow | - |
| Task [SF] - Notification - Next Step Date Slip | Autolaunched Flow | Schedule |
You might ask: couldn't I just filter the flow list by triggering object? You could, but that misses screen flows and autolaunched flows built for that object, because they have no triggering object.
The naming pattern we recommend
[Object Name] [Flow Type] - [Record Type, if applicable] - [Flow Synopsis]
Flow type abbreviations
| Abbreviation | Flow type |
|---|---|
AS | After Save (record-triggered) |
BS | Before Save (record-triggered) |
BD | Before Delete |
SCR | Screen Flow |
AL | Autolaunched Flow (called by other flows, buttons, or Apex) |
SF | Scheduled Flow |
ASYNC | Asynchronous path |
FSL Mobile | Screen flow built for the Field Service mobile app |
One last piece of advice
Once you're convinced that naming standards matter across flows and all your other metadata, there is one more rule: remove the underscores from the API name. A clean, readable API name that matches the label is far easier to search for, reference, and maintain.