Flow General Notes

Generalities

As of writing this page, DecemberOctober 12th8th 2021,2023, Flows are very much on their way to be the primary source of automation on the Salesforce platform. 
TheyWe willleft undoubtedlythis fullysentence because the earlier iteration (from 2021) identified that Flows would replace Process Builder withinand roughlywe like being right.

It is very important to note that Flows have almost nothing to do, complexity-wise, with Workflows, Process Builder, or Approval Processes. Where the old tools did a year,lot andof will(over)-simplifying probablyfor beyou, madeFlow exposes a lot of things that you quite simply never had to replacethink Workflowsabout and Approval Processes after that, I would guess within the next 3 years.

Most of the advanced administrators will welcome this change. After all, Flows are more powerful than anything else, and are more maintainable than Process Builder (learning curve notwithstanding).
They do however introduce quite a few problems that were previously hidden from the Administrator,before, such as loopingexecution andcontext, bulkification.DML Thisoptimization, isn'tbatching, badvariables, pervariable se,passing, but it adds yet another level of complexity to administrator knowledge.  etc.
To reference the diagrams in the official Architect Decision Guides, things are getting easier to break while adding more functionality.

So what we're saying in this introduction is Ifif you are an Administratorold-timer upgrading your skills, note that a basic understanding of programming (batch scripting is more than enough) helps a lot with Flow.
If you're a newcomer to Salesforce and you're looking atto learn Flow, same comment - this is harder than most of the platform (apart from Permissions) to learn and manipulate. This is normal.

On Conventions

As long as we're doing notes: conventions are opinionated, and these pagesare no different. Much like you have different APEX trigger frameworks, you'll find different conventions for helpFlow. These specific conventions are made to be maintainable at scale, with an automationease withoutof knowingmodification muchand aboutupgrade. Flows,This pleasemeans takethat athey momentby tonature reviewinclude howboilerplate that you might breakfind stuffredundant, when/ifand itspecify fails.

very

Asstrongly aelements final(to quickoptimize introductorycases paragraph,where yesyou wehave knowhundreds theseof ConventionsFlows arein muchan moreorganization). annoyingThis does not mean you need to follow thaneverything. A reader should try to understand why the onesconventions are a specific way, and then decide whether or not this applies to their org.

At the end of the day, as long as you use any convention in your organization, we're good. This one, another one, a partial one, doesn't matter. Just structure your flows and elements.

On our Notation

Finally, regarding the naming of subelements in the Flows: we've had conversations in the past about the pseudo-hungarian notation that we recommend using. To clarify: we don't want to use hungarian notation. We do so because Flow still doesn't split naming schemes between variables, screen elements, or data manipulation elements. This basically forcesyou to use hungarian notation so you can have a var_boolUserAccept and a S01_choiceUserAccept (a variable holding the result of whether a user accepts some conditions, and the presentation in radio buttons of said acceptance), because you can't have two elements just named UserAccept even if technically they're different.

On custom code, plugins, and unofficialSF

On another note: Flow allows you to use custom code to extend its functionality. We define "custom code" by any LWC, APEX Class, and associated that are written by a human and plug into flow. We recommend using as little of these elements as possible, and as many as needed. This includes UnofficialSF.

Whether you code stuff yourself, or someone else does it for Processyou, BuilderCustom Code always requires audit and Fields.maintenance. Deploying UnofficialSF code to your org basically means that you own the maintenance and audit of it, much like if you had developed it yourself. We emit the same reservations as using any piece of code on Github - if you don't know what it does exactly, you shouldn't be using it. This is because Flowsany third-party code is not part of your MSA with Salesforce, and if it breaks, is a vector of attack, or otherwise negatively impacts your business, you have no official support or recourse.

This is not to say that these things are morenot complex.great, Pleaseor remembervalue-adding that- webut tryyou toare make(probably) thesean onlyadmin asof annoyinga ascompany neededCRM, which means your first consideration should be user data and ascompliance, leanand asease possible.of use coming second.

_{Bonus useless knowledge: Flows themselves are just an old technology that Salesforce released in 2010: Visual Process Manager. That itself is actually just a scripting language: “The technology powering the Visual Process Manager is based on technology acquired from from Informavores,  a call scripting startup Salesforce bought last year.” (2009) Source}