<span id="hs_cos_wrapper_name" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="text" >Salesforce Flow Best Practices: Naming Conventions</span>

Salesforce Flow Best Practices: Naming Conventions

Salesforce Flow requires you to name lots (and lots) of different things. Every Resource, Element and Outcome requires a label and an API Name. If you don't have a consistent approach to naming, it gets confusing fast. This is our (opinionated) guide to naming things in Flow.

Caveat 1 - These are just opinions. Gradient Works uses Flow for rules of engagement automation. Between us and our customers, we've worked on hundreds of Flows for lead routing, opportunity assignment and any other handoff process you can imagine. This approach has worked well for us, but your mileage may vary. There's no right way to name things in Flow. Do what you want, just please be consistent. Your team and your future self will thank you.

Caveat 2 - This is written from an English language perspective. If you're not building Flows for an English-speaking audience this may not apply to you.

With those caveats out of the way, let's get to it.

The naming conventions

For those of you that are used to using Flow and don't need too many details, our recommended naming conventions are below. Just FYI, a reference version of this is available for download in our Flow Quick Reference.

  • Use Snake_Case for all API Names
    Name your Resources and Elements using capital first letters and underscores to separate words. If you strongly prefer CamelCase (or camelCase), go for it. The other conventions below still apply just as well.
  • Use nouns for Resources
    Resources represent “things” (variables, formulas, etc) that hold data for you to access. It makes the most sense to name “things” with nouns.
  • Use verbs for Elements
    Elements represent actions the Flow takes. Give them active names that use verbs to describe what you’re doing (e.g. label "Get Lead", API name "Get_Lead"). Because of their special branching behavior, Decisions and Loops are special cases (see below).
  • Decisions
    Decisions represent points in your Flow where you can "branch" to take a specific path based on specific conditions. This means you need to name both the Decision itself and specific Outcome paths.
    • Name the Decision with a question
      Frame Decisions as a question (e.g. Label “Is Open”, API name "Is_Open") and your Outcomes as answers to that question (“True”, “False”). This also applies to non-binary Decisions (e.g. “Which Territory” with outcomes for North, South, East, etc).
    • Prefix Outcomes with the Decision name
      Each non-default Outcome in a Decision has its own API name. To make it easier to find, prefix it with the API name of its decision (e.g. “Is_Open_True” for the True Outcome API name of the “Is_Open” decision).
  • Use Each for Loops
    Loops let you do something with each item in a Collection, one-by-one. If you’re looping over a Collection of Users, name your Loop “Each User”. For Elements inside the Loop, you can refer to “Each_User” to access the current item.

Naming basics with examples

If you're just getting started with Flow or moving to Flow from Process Builder, let's clear up a few details.

Where do the names go?

When creating a new Element (in this case a Gradient Works Match Lead to Account action, but the same applies to any Element), you'll see a screen like this one:


Every Flow Element provides three fields: a Label (1), an API Name (2) and a Description (3). For Elements, the Label should be a brief active phrase, usually starting with a verb. This is what will be displayed on the Flow Builder canvas. The API Name cannot contain any punctuation besides underscores and will be what you use throughout the Flow to reference this Element. If you provide a Label and leave API Name blank, Salesforce automatically converts your API name to Snake_Case by replacing spaces in the Label with underscores (e.g. the label "Match Lead" becomes "Match_Lead" for the API name). We recommend that you follow that convention.

Creating a Resource looks similar but without a Label:


Resources have an API Name (1) and a Description (2). They do not have a Label. You'll always see Resources listed using their API Names.

Click the pencil to edit names

You can always change the name of an Element or Resource later. To do this, just edit the Element or Resource and click the pencil icon (1). When you rename something, Flow will automatically update any references to that name anywhere else in the Flow. Make sure to keep your Labels and API Names in sync when making changes. It can be confusing to have a label called "Assign to Rep" and an API Name of "Assign_Lead".

Editing an Element looks like this: EditElement

Editing a Resource looks like this:


Naming Decisions and Outcomes

Dealing with multiple Decisions and Outcomes is one of the more powerful (and more complex) features in Flow. Flow supports much more complicated approaches to branching than Process Builder so this is where people transitioning to Flow from Process Builder often get tripped up. This is why we think it's important to pay special attention to naming these Elements.

Here's a pretty standard Decision element that checks whether or not a Lead has an open status:


The Label (1) is in the form of a question and the API Name (2) is in Snake_Case. The first outcome is labeled True(3) because it represents an "answer" to the Decision question. In order to keep things organized, the Outcome API Name (4) is a combination of the Decision API Name and the Outcome API name. We'll see in a moment how that makes things easier to find later.

The last name change we need is to rename the Default Outcome so that it represents an answer to the question posed by the Decision name. Here's what that looks like:


In this case, the "answer" to "Is Lead Open" is "False" so we set the Default Outcome Label (1) to say so.

Here's how all this plays out in the Flow Builder:


Hopefully, you can see how this helps us stay organized. The Decision (1 and 4) is framed as a logical question. Each decision Outcome branch is clearly labeled on the Builder canvas (4 and 5) as an "answer" to the question posed by the Decision. In the Resources panel on the left, you can clearly see that the Decision Outcome called "Is_Lead_Open_True" (2) is related to the "Is_Lead_Open" decision and represents the "True" branch.

This is even more helpful if you have Decisions with more than two outcomes. In that case, all the outcomes that relate to that Decision will be logically grouped together in the Resources panel.

Do these things next

Happy Flowing!

Related Posts

Dealing with conflict in your rules of engagement?

Download our free rules of engagement toolkit, for sales and operations leaders. Get RoE templates, flowcharts, a discussion guide, tips and more.