Most Salesforce Admins in today’s world do not have a background in development. Most aren’t involved with coded solutions that are created to enhance Salesforce’s capabilities. There are a select few that are both developer and admin, and some have an understanding of development and how it works, but for the most part, do not actually code themselves.
Enter Salesforce Flow Builder
This tool has been built by Salesforce as part of their “Clicks, Not Code” initiative to allow those of us in the Salesforce ecosystem that are admins to code declaratively instead of programmatically. A staggering 74% of IT leaders have stated that they currently use or plan to use low code development over the next year. This means that things like Flow will most likely begin to take over in the years to come, and, as developers, it would behoove us to get to know them.
Now, personally, I started out as an admin while I was in college for Computer Science (you can read my story here). My admin skills mixed with my knowledge of coding allowed me to make a smooth transition into the realm of Salesforce development. I was approached by my team lead earlier this year, and he asked me to take a look at Flows and figure out if I could design a Flow to easily run a record creation wizard in our internal org. This is when I began my journey with Flows, and learned so much about this relatively new Salesforce Lightning feature. Below, I am going to delve a little deeper into working with Flows as a developer and how they relate to code.
Advantages of Flows
As I said earlier, one of the main reasons for Flows is they make some code solutions available to non-developers. Not only that, but they also are easier to update and maintain than code for those non-developers.
Version Control
Developers are familiar with the benefits of version control systems, like git. We have the ability to commit changes to our work, see the entire history, and roll-back to a previous version if necessary. Flows offer a basic implementation of versioning, similar to that which is seen with Process Builder. New changes don’t overwrite previous Flows, but create new versions, providing a bit of a version history, while only one is marked active at a time. This allows you to easily revert back to a previous known-good and working version, should something go wrong with recent changes. The nice part about this is that we, as developers, fully understand this concept already and can very easily navigate between different versions. My biggest advice here is to always make sure that you know which Flow version is active and running in your org.
Portability
Similar to code, Flow has the ability to use custom, open-source components that are built by others on the web. Most can easily be installed by grabbing a package link from a web page and installing it in your org! From that point on, you can pull the code down into your repo and fully understand how it works. Another plus side of this functionality is that you can also develop your own custom components to work with your Flows and make the UI more streamlined for your users.
Collections
An integral part about working with Flows is the collections variables that can be used to store an assortment of records, strings, dates, etc. These collections are the closest things that we as developers get to lists. Most of the time, you will be using these variables to store a list of records that you have retrieved through a Get Record component in the Flow (a Get Record component is the equivalent of a SOQL query returning records in Apex). They can also be useful for storing record id’s to be passed to an Invocable Method, which I will talk about later.
Debugging
Debugging is a huge part of testing and error resolution in the development world, and now non-developers can use the “Debug” button in the top right of the Flow builder to run through the Flow and see if any errors occur.
After Clicking the debug button, you will be taken to a screen with some options for how you want to run the Flow:
Then, once you have selected how you want to run the Flow, you are brought to this screen:
Here you will see any errors that the Flow may have hit while it was running. This is extremely helpful because it gives a less raw version of what developers are used to in the Debug Logs in Dev Console and also shows each step the Flow takes.
Disadvantages of Flows
As with anything that is new, there will be a learning curve. As a developer, I would have been able to build a Lightning Web Component (LWC) that did what the screen Flow was doing in half the time because I am more familiar with LWC’s. But, the reason a Flow was wanted was for maintainability by an admin in the future rather than having to pull a developer in to make changes.
As of right now, some Flow solutions have proven to be too convoluted to use for some use cases. A perfect example is cloning a group of records. It is much easier and less time-consuming to build an Invocable Method that can be called by the Flow, which we will talk about later. The main problem with this issue is that the method would still need a developer to be able to maintain and make updates to it in the future, so it takes away from the advantage of having solely admins maintain the Flow.
Salesforce has proven that they are dedicated to bringing Flows up to speed with coding and are working towards adding new features with each release. See my colleague Sarisha’s post on Winter ‘22 Admin Features that highlights her favorites, like the new Flow Orchestrator. A useful update would be for Salesforce to add a Flow equivalent to the Apex Maps data type. Maps have proven time and time again to be extremely useful to developers and having that kind of capability in Flow would take it to the next level.
Another practical update would be to allow upserts and partial DML operations. As of now, Flows can only insert, update, and delete records. This leaves much to be desired when working with records that may be duplicates. Partial DML operations would also be a fantastic addition as they allow developers to insert/update/delete whichever records did not error in the Flow process, something that is possible with “all-or-none” options in Apex (also seen as an option amongst the standard Data Loader’s options).
Code and Flow Meet in the Middle
The other nice part about Flows, especially as a developer, is you can create Invocable Apex Methods that can be called from the Flow. This is helpful when you need to do something like cloning a group of records or doing a DML operation (such as upsert) that might not yet be available in Flows.
My main caution with Invocable Methods is that they only allow one parameter. This parameter can be a collection or just a regular variable of any type available. If you need to pass in multiple values, I would recommend building out a collection of strings in a specific order in the Flow in order to then grab each manually using array notation in the Invocable Method. (Sidenote: When you pass a collection to an Invocable Method, it comes through as a List of Lists, with the first element in the parent List containing the collection variable passed from the Flow)
Example:
So, Do I Go With The Flow?
The end result of what you decide to use will be based solely on the use case of the functionality you are trying to build. Feel free to use the advantages and disadvantages I have laid out as a guide as to whether you should use code or a Flow.
As a quick review:
Advantages:
Admin maintainability
Built-In version control
Custom components
Collections variables
User-friendly debugging
Disadvantages:
Learning curve (as a developer)
Code less complicated for some use cases
Missing capabilities that code has:
Maps
Upserts
Partial DML Operations
Best of Both Worlds:
Invocable Methods to be used with your Flow
Disadvantage: still need developers for maintainability
So, in the long run, going with the Flow is entirely based on your use case, and can certainly make your life easier in the future, as they are not capitated only to developers like code is. Salesforce is coming out with new features with every release, so be on the lookout for more and more improvements in the coming years!
Sources:
