We all have seen that Salesforce has been announcing for a couple of years now that they would retire automation tools such as Workflow Rules and Process Builder. As a Salesforce Administrator, I would like to state some ideas around these ongoing changes and their replacement with the Flow Builder.
Salesforce has many times expressed their concern about making the Flow Builder more friendly towards Admins. They have been focusing efforts on making the Flow Builder more intuitive and easier to use, having as their main target Administrators, why? Bear in mind that they refer to the flow as " the future of low-code automation".
Now the time is here. We have started to see the “Migration to Flow” tool available to move older workflow rules automation to Flow Builder, and even more, by Winter ‘23 (October 22) we will not be able to "create" a new workflow rule at all, and apparently, by Spring ‘23 (February 23) the functionality to "create" a new process (builder) will be turned off.
Problem solving challenges
Admins have always been given the challenge to solve problems that requires non-human direct interaction, such as: taking away repetitive manual work from end-users, blocking records when some criteria are met, showing/disappearing something when a button is “clicked”, and many other things that a user themselves would not remember because this would be a part of a bigger process that should be running in the back-end. This is where automation comes in place, and the need to figure out declarative configuration to make all this happen.
Whenever possible the best practices, according to Salesforce, are to scale from OOB/easier up to more complex solutions, where code would be included to become part of the game. This is the main reason why, we admins, have the responsibility to become better to resolve complex business processes and avoid writing code where it fits, and hence our best bet is to learn Flow Builder now when we still have time.
Skip difficulties and avoid complexity
When we are in a project to implement Salesforce in a small or medium size company, the main concerns we often hear is “we do not want something complex”, “we want to skip difficulties”, “we want to be able to fix things on our own in the future”. Many of those companies must put employees that are not necessarily developers or IT-related professionals to take on those projects, then it is imperative to think of a best way to make it possible for the users who will inherit the solution to make changes independently as often as they need. Not only are we helping each company handle things easier but also saving them extra cost for further modifications if they are not able to deal with programming.
Now, we understand that customers do not want “complex” or “difficult” solutions, however, we also face a time in which their business processes tend to become very complex along the way. What a predicament! But this is also how Salesforce has been thinking about it, and we admins would need to embrace it: the Flow Builder offers every feature that the old automations together or separately would offer to cover for those complex and inevitable processes, and more: from update the record that is being modified/created, to update or create a record that is related to the main record, or more advanced: find all records related to the main record that meet a given criteria and modify them at once, and then send an email to the owner of the related record and post in chatter to the owner of the main record, and so many possibilities, you name it!
I do remember the Flow as the old Flow Designer, the same point-and-click principle but super hard to understand, it was a more primitive builder that many developers of course would not have any problems dealing with. I also used to see so many complains from Admins in the Salesforce Ecosystem about the difficulties they (we) had to understand and make them work. It was dangerous, if you did not connect something correctly, or were missing a piece of condition, or any other detail.
The evolution of Flow Builder
Nowadays, after many releases, and really listening to us, Admins, the evolution of the Flow Builder has become visually appealing, nicer and easier to understand and use, for instance, Record Collection Variables or Record Single Variables are self-created when you use a “Get Records” or a “Loop”. I cannot deny that it has its long learning curve, especially if you have a background like mine -off the orbit- far away from the engineering world. Nevertheless, I can affirm that IF we learned workflows and processes THEN we can learn Flows as well.
I would think that it is very important to get started as soon as your mind and heart leads the way. Because we need to understand its elements first, it could be little hard at the beginning to get how each piece interact with each another, and how we modify records inside Salesforce after we are done with this interaction; basically we would need to think more or less like a developer does - I know, I have been speaking with developers to try to get into their brains and try to extract the logic on how they actually see things, it is helpful. I can put it like this: we bring a dataset into the Flow Builder through conditions, we change some values from each record through single variables, then we set those variables aside on a collection variable and then we use this collection to actually update the records we brought in back inside Salesforce.
Image on the left: The assignment of each public group by profile is determined by Custom Metadata Types, which can be called from within the Flow as "Data", giving us the possibility to drive this "combination" from outside the flow without hard-coding.
Image on the right: This Flow Builder exemplifies how we could automate the assignment of Public Groups to newly created users or users who's profile has been modified.
Whilst there is a lot to learn when actively preparing oneself, some last thoughts would be that when we are in doubt it is important to discuss with colleagues who may be more adapted to the programming-way of thinking, such as developers or a technical architect, to really make sure that flow builder is more suitable than triggers or code, as flows offers many possibilities, such as direct interaction with a human (Screen Flow), making changes on the background (Record-Triggered Flow), set a time and date to make a change (Scheduled-Triggered Flow), etc. The time is here and each one has the control to learn. Salesforce has many venues plus there are many passionate and knowledgeable people in the ecosystem who would never let us down… Go with the flow!
