We’ve all been there, where you’re learning to write your first Visual Flow. The main thing we’re focused on is just making sure that it is functional. That’s fine while you are in your Sandbox developing, but once you’ve got it working correctly you need to make sure your Flow follows these five best practices.
Elements are Organized
One of the top rules for writing code is using proper indentation. David Liu (SFDC99) is known for his love (or OCD) of clean code. Visual Flow’s equivalent to indentation is the alignment of the elements into a clean format. Think of it like you’re having company over – you would make sure you cleaned your house up before they arrived.
Your Flow should be very easy for you to follow the Flow Elements from start to finish without having to strain your eyes. Keeping it clean also lets your Flow be easier to make future updates to it. You don’t have to take apart your Flow to make sure you didn’t miss anything on your update. So, be sure you spend the extra minute or two to make sure your Flow is sharp looking!
Bad
Good
Naming Convention
In the developer realm, camel Case is the standard. In Flow, we’re stepping into the developer world without really having to write code. It obviously isn’t required that you use camel Case as your naming convention, but it is important that you follow a consistent naming convention. If you don’t, your Flow will be much harder to read.
Variable Names
In addition to your naming conventions, you need to make sure your variable names make sense. I have opened up way too many Flows that use variable names that are not clear. If someone has to do some detective work to figure out what your variable is doing, you need to rethink your variable naming. Variable naming can often be hard to do correctly, because you have to summarize the function of the variable into a small concise variable.
Do: CaseId — Don’t: RecordId
Why? RecordId is very generic and does not tell me what Object it is referring to. I would have to go find where the value was assigned to see the Object it is the Id for. CaseId is clear and I don’t have to do any research to figure out what it is.
Fault Messages
When your Flow fails its important for everyone to be alerted. If you’re a Solo Admin, then you can technically get away without using a Fault Message, because Salesforce’s Email Alert will go to you. However, if you have more than one person developing in your Org, this is a requirement! By setting up a Fault Message, you can easily alert all of the Admins and Developers of the issue.
It is also important to use multiple Fault Messages inside your Flow. You’re able to customize the Email being sent out to provide specific information that pertains to that particular part of your Flow. This will help you as you troubleshoot your Flow.
Descriptions
Make sure you use Descriptions in your Visual Flow. This goes along with having your Flow Elements all aligned and easy to read. You want your Flow to be easily digestible. It is important to not write blatantly obvious Descriptions, just to write them. You want to make your Descriptions helpful.
Anytime you have to do something unique inside your Flow you should include a Description to explain what, and more importantly why. An example would be when you use a Formula in your Flow.
Recap: Think long term when you’re building your Flows (or anything). Just like you want to create a good User Experience for your End Users, make sure you create a good one for the Admins & Developers that are maintaining the Org. None of these best practices require a significant amount of time to follow, and the benefits of having a clean Flow will be worth the extra effort! And if you’re still reading, make sure you check out my The 6 Most Common Visual Flow Errors to Avoid.
When you’re working inside Process builder, you’ll see a chevron next to any related object that you can navigate to. This lets you then reference the fields of that Object in your Criteria and Actions.
Salesforce Sidekick 