Hello folks,

This is the first of many weekly “Salesforce Flow Tips” weekly emails that you will find in your inboxes in the coming months.

Today I will focus on decision elements and how they work in flow. I have done a comparison of two flow images on Twitter and Linkedin before and the post attracted a lot of attention. It turns out Zuckerberg had the right idea originally, and people do like to compare two images and decide which one is hot and which one is not.

Emailing back and forth is such a boomer thing to do, so we won’t do that. Instead, I will give you links to my posts with the same exact content, and I encourage you to think about the topic and comment your take on one of the platforms where this is posted. Here we go:

What you see in these pictures is two versions of the same use case implemented. These flows just capture the decision outcomes when an Opportunity Stage changes from Prospecting to Closed Won or to Closed Lost.

You can find this post on Twitter, Linkedin, and Slack. Just click on the platform name.

I will give you my take next week after I learn from all your posts and digest a final evaluation making me look more clever than I really am.

Another topic I want to touch on is the naming convention inside your flow for resources.

A few tips on naming your flow resources:

If you are using search in your toolbox resource manager, it may make sense to use the type of resource you are creating in the resource name. I don’t like to abbreviate personally, so my resources will have choice, formula, and variable in the resource name, such as YesChoice and ResonPicklistChoice.

If you use the resource manager to visually look for the resource by scrolling down, you will find that your resources are grouped by type under the relevant section.

I like my resources sorted by what they do rather than their resource type; therefore, I do not use a prefix in the name; I append the type to the name. This depends on your personal preference. I will have two resources that start with the same word that explains the use, like ReasonPicklistChoice and ReasonOtherTextVariable.

This naming convention also makes the best use of autogenerated API names out of labels in your screen flows. You append the resource type to the autogenerated name, and you are done.

You can abbreviate variable in the name and use var, for example. This is also your personal preference; folks prefer this because long names get cut off sometimes when they are displayed in the UI.

If you cannot be consistent with abbreviations, the long version is better than the short version.

And finally, you see from the examples I gave above that I like to use CamelCase, but this also depends on your preference. When the API auto-creates a name with _ characters, I leave them in. Please give me your feedback under the relevant post on Twitter, Linkedin, Slack, or Youtube channel. Please do not send a connection request on LinkedIn; follow my profile instead. You can certainly reply to this as well; this would be my least preferred channel.

Please remember that there is a giant team of one person behind the Salesforce Break group of activities. If you like this email, please forward it to others. Also, if you received this email from somebody else, you can subscribe to the flow tips newsletter here. You are receiving this email because you gave me your email address when you signed up for a free Salesforce Flow live session either on Superpeer or Eventbrite, or you filled out the “Contact Me” form on Salesforcebreak.com. Your email was added to an email list on a professional email newsletter platform just for this educational newsletter. If you do not want to receive this email, please unsubscribe below, and you won’t be bothered again.

Enjoy

P.S. Originally published on 11/07/2021.

You can read the next issue of the newsletter here.

You can subscribe to the weekly educational Salesforce Flow Tips Newsletter here.