Welcome to week 4 of Flow Documentation Month. Across the month of March I’ve been putting together a series of posts on the subject of Flow Documentation, this is week 4 of 5 of the series, and today we’ll be talking about the topic of naming conventions. Naming conventions is a very important talking point in the world of Flows. But what exactly are we talking about when we say the words, naming conventions? Well, in this post that’s what we’ll be talking about. To provide a bit of a spoiler, I don’t feel it is my place to tell you what naming convention to use, so in this post I’m going to talk about what naming conventions are, the three naming patterns we can use in Flow and then I’ll wrap up my talking about what naming pattern I use and why I use it.

N.B. Before we dive into the topic overall, if you haven’t read the previous posts in this series, you can check them all out here.

Let’s begin by talking about what a naming convention is.

What is a Naming Convention?

When we talk about naming conventions in the Salesforce space, we’re generally talking about this in a way that is more or less the same to what we would mean by naming conventions in computer programming. In a nutshell, a naming convention is how we name variables and functions within the code that we build (technically anytime we create something in Salesforce, we create code, even if we create something in a declarative or point and click method … often we refer to this code as metadata). For us who come from an Admin background, this concept might be a little foreign to you, so my hope here is to explain this concept in a way that is helpful and beneficial to you. If you’re reading this as someone who comes from a dev background, this information is most likely something you know even better than I do (so I’d love to hear your thoughts on the subject in the comments section below).

The naming convention we use in Salesforce refers to the rules we set and the approach we take to naming the API and Developer names of items such as fields, Lightning Record Pages, Actions and many other things. In terms of Flow specifically, the naming convention that we use will mainly apply to the API names of the elements and variables within our Flow, along with the API name of the Flow itself. That is basically all that needs to be said about what a naming convention is. The real meaty area of discussion when it comes to how we use a naming convention within the Flows that we build is actually around the naming pattern that we use. So we’re going to move now to talk about naming patterns, more specifically the three naming patterns we can use in Flow.

The Three Naming Patterns We Can Use in Salesforce Flow

When we talk about naming patterns for the API names that we use in Flow, it doesn’t hurt to be aware of the three naming patterns that we can use in Flow Builder, and more widely across Salesforce. In the world of programming there are four fairly common naming patterns that are used. In the world of Salesforce, we can only use three of those four naming patterns.

The naming pattern we can’t use is known as Kebab Case. Kebab Case is a naming pattern that uses two or more words to describe an item and places a hyphen (-) between each word. Kebab case doesn’t require capitalisation of the beginning of words, or all letters within a word, however if you capitalise the entire name of an item this is known as Scream Kebab in the programming world. Examples of Kebab Case would be get-contact-records, GET-CONTACT-RECORDS, Get-Contact-Records. Like I say, we can’t use this naming pattern in Salesforce, this is because Salesforce don’t allow for hyphens in API names. That being said, I thought it was a good idea to cover this naming pattern briefly just so that you are aware of the naming pattern we can’t use.

Let’s now pivot to talk about the three naming patterns we can use in Salesforce and more specifically in Flow:

The first naming pattern on my list is Snake Case. Snake Case is the naming pattern that places underscores between each word including in a name. If you’ve been building Flows for a little while you might recognise this pattern as Salesforce use a variation of Snake Case for their default API naming pattern.

The second pattern on the list is Camel Case. You’ve probably heard a number of Flow experts talk about Camel Case, as it is one of the more popular naming patterns used in the realm of Flow. Camel Case uses multiple words, with the first word being all lower case, and each subsequent word being written in Title Case (first letter capitalised) e.g. getContactRecords.

The final pattern on the list is known as Pascal Case. This type of naming pattern is similar to Camel Case but it has one key difference. That difference is that the first letter of each word in the name is capitalised. An example of Pascal Case would be GetContactRecords. This is available to use in Salesforce.

In terms of which naming pattern you use, as I stated at the beginning of the post, I don’t feel it is my place to tell which pattern to use. However, what I do want to do is to encourage you to be consistent with whatever naming pattern you choose to use. What I mean by this is that it is best practice in my view to pick a naming pattern to use and to stick with it. Just to be clear, what I don’t mean by stick with it is use it forever … for example, if you start out using Snake Case and then decide to switch to Camel Case at a later date because your views on the subject of naming conventions and patterns have changed, I think that’s OK. What I am really referring to by sticking with it, is to avoid changing naming patterns every Flow you build in a short period of time, and even more importantly don’t mix and match naming patterns within the same Flow (this is a big no no). In my view, consistency is important. Being consistent with how we put together our API names in Flow allows us to keep things organised and keeps metadata clean.

Now, as we begin to close off this post, let’s talk about what naming pattern I prefer to use.

What Naming Pattern Do I Prefer to Use in Flow?

Personally, I prefer to use Camel Case for the naming pattern that I use in Flows. This because in my mind it makes the API names more organised. For example, if I’m using a record variable in a Flow I will preface the api name with rec, so when I look at the list of all of my resources I can very easily see all of my record variables in a grouping because they will all start with the preix of rec. Likewise, in a Screen Flow I give all of my input components a prefix of input, this allows me to easily see from my list of resources all of the items in my Screen Flow which require User Input in order to use those values elsewhere within the Flow that I build.

I’ll wrap up this section with examples of what I do for my naming patterns in Flow, but again what I want to stress here is that as a Flow builder you should really look to do what works for you. Yes, there’s benefits to doing things like adding prefixes to API names so that you can keep your list of resources organised and easy to manage. But, the pattern you choose to use should work for you as the Admin building out Flows, and for the organisation that you work for. So if it makes sense for you to stick with Salesforce’s default variation of Snake Case, then stick with that. If it makes sense for you to use Camel Case like I prefer to, then go with that. I think it is far more important to be consistent with your naming convention practices than it is to use a specific naming pattern.

Let’s bring the ship in to land with what I currently use for prefixes in the naming pattern I pefer to use. Please note that this list might look slightly different in 6 months time … but this is what I currently use for my naming patterns when I build out Flows.

Below is a list of examples of how I currently put together my naming conventions in Flow:

Variables and Resources:

Record Variables = recObjectName e.g. recContact
All other Variables = varVariableItem e.g. varCloseDate
Formulas = formulaFormulaName e.g. formulaCloseDate
Text Templates = templateTextTemplate e.g. templateNotificationBody
Choices = choiceChoiceName e.g. choiceYes
Collection Choice Sets = collchoiceChoiceName e.g. collchoiceMailingCity
Record Choice Sets = recchoiceChoiceName e.g. rechoiceAvailableContacts
Picklist Choice Set = pickchoiceChoiceName e.g. pickchoiceFavouriteColour

Elements:

Screens = screenScreenName e.g. screenLogContactValues
Subflow = subflowSubflowName e.g. subflowSendCustomNotification
Assignment = setAssignmentName e.g. setContactValues
Decision = decisionDecisionName e.g. decisionIsContactActive
Loop = loopLoopName e.g. loopContacts
Collection Sort = sortSortName e.g. sortContacts
Collection Filter = filterFilterName e.g. filterContacts
Create Records = createCreateName e.g. createContact
Update Records = updateUpdateName e.g. updateContact
Get Records = getGetName e.g. getContacts
Delete Records = deleteDeleteName e.g. deleteContact
Roll Back Records = rollbackRollbackName e.g. rollbackRevertChanges

Hopefully this list above is pretty much clear. At this stage I don’t think I need to do too much of a deep dive into my particular choices for naming conventions, if that is something you want to see I can do that in a future post. Let me know in the comments below if you’re interested in seeing that. I’d be more than happy to do that, but I don’t think that I need to do that for this post.

Closing Comments

So that’s a bit of an overview of naming conventions and naming patterns in Flow. This topic is quite extensive, and I could easily talk a lot further about that in future posts. But what did you think? How do you name your API names in Flow? Is it similar to what I do. What improvements could I make to how I name the API names within Flow? I’d love to hear your thoughts in the comments section below. This is an area that I think we could all learn a lit bit from each other on. So I’d absolutely love to hear your thoughts. Next week is the final week of this series and we’ll be talking about how you can create a Flow Documentation strategy. I felt it was important to tie-up everything we’ve been talking about with a post about some of the principles around not only documenting your Flows, but ensuring that you keep that documentation up-to-date as you continue to iterate on what you build going forward.

Until then, I’d love to hear your thoughts on today’s subject. Stay well, and I’ll talk to you again next week.

Resources

We have three resources to link to this awesome post … all of the posts for this post cover various items around naming patterns and naming conventions for Salesforce Flow. The first resource is one that provides a little more insight on the naming patterns of Camel Case, Snake Case and Pascal Case. The other two resources for this particularly focus on naming conventions inside of Flow.