Salesforce Flow Naming Conventions and Why It Matters
An often overlooked component of building on the Salesforce platform is metadata naming conventions; especially API naming conventions. At the surface, it might seem irrelevant to have an agreed-upon pattern for naming elements as who really cares how things are named on the backend? Only the administrator and salesforce team will be impacted by implementing a standard and isn’t it their job to figure out how things work? Sure, it might seem pointless but the value in upholding standard naming conventions will create a backend that is easier to understand, work in, and navigate across time. The team that is working in your Salesforce instance today will not be the team that is there in the future and implementing rigid design standards will create an environment that is easily understood by all and allow for easier identification of what elements are part of a process - i.e. admin serviceable design (if not familiar with this term read our blog post!).
YOU GAVE THE FLOW WHAT NAME???
Let’s look at Flow. Flow at this point has become the real workhorse of Salesforce and you are going to have a lot of flows whether you want to or not. Imagine if we had a lot of different automations on the task object which has several different record types. Lets say we start building some flows and giving them names such as Update Task Due Date on Sales Task, Set Task Owner at Creation, Complete Task Screen. Then imagine that some of these flows only pertain to a specific record type. So you get a new requirement to add additional automation to the task object for a specific record type. How do you quickly know what flows you have on that object and record type? How do you know if you should build a new flow or add logic to an existing? The short answer is you have no clue as you lack a naming convention strategy and might also be lacking a flow automation strategy (learn more about flow frameworks).
Let’s take a step back and rename these existing flows.
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 that we have implemented a standard naming convention for the task flows we can create Object Specific list views and easily understand what flows we have! Isn’t that beautiful! If you’re being knit picky you might be asking yourself couldn’t I just filter a flow list view by the triggering object? Sure, you could filter by the triggering object, but how would that include screen flows built for a specific object?
Now that you see the value in this approach here is our recommended naming pattern: [Object Name] [Flow Type Abbreviation] - [Record Type (if Applicable)] - [Flow Synopsis]
Flow Type Abbreviations
AS = After Save
BS = Before Save
SCR = Screen Flow
AL = Autolaunch Flow
ASYNC = Asynchronous Flow
BD = Delete Flow
FSL Mobile = Screen flow specific to the FSL Mobile App
Now that we have exacerbated and convinced you that it is invaluable to have naming convention standards across flow and all metadata we just have one final piece of advice: REMOVE THE UNDERSCORES FROM THE API NAME!
