During the month of February, I worked with a consultant to move just ONE process builder over to Flow, and it was an ADVENTURE! In this blog post, I will write about some of the challenges, avoided (!) pitfalls, learnings, and maybe even some advice as we, collectively, face this huge change in the Salesforce admin toolbox.
Step 0.1: What does the PB do?
A few years ago, we had taken the “best practice” advice of moving all of our PBs to One-P-B-Per-Object. It was tedious, time consuming task. The reality is, I’m SO glad we did that. In the intervening years, I was able to update, modify, and generally maintain this automation with more precision and acuity. Additionally, we were able to control the general “order of operation” *within* the PB, since there is no way to control the order of PBs tied to the same Object (a feature that is now available in Flow).
This blog post focuses on automation for our Payments Object. The Payment is a “child record” to Opportunities. Since we are a grantmaking organization, we have a very intricate process for scheduling and approving payments.
The automation:
- Sets certain field values when the Payment record is created
- Updates field values when the Payment record is edited
- Updates field values on related records
- Enters the Payment into an approval process based on certain eligibility criteria
- Our use case does not require creating any new related records
I chose this PB to migrate to Flow because we were encountering a known issue where payments created by inactive users (back in the day!) were rejected from entering the approval process when the payment date finally came around (payments are scheduled years into the future, and sometimes staff leave). For years, we have manually fixed these on a monthly basis. However, getting this to work properly seemed like high ROI and good motivation to get started with record-triggered Flows.
This is not just a problem for Submit for Approval, but rather, any scheduled action in Process Builder that was originally set into motion by a user who is now inactive.
Step 0.2: Where am I in my Flow journey?
Around two years ago, I got my toes wet in Flow and frankly, had a somewhat agonizing time (don’t let this discourage you, Flow has gotten better since then!). The special Flows that we needed involved sophisticated Screen Elements and conditional logic, and looping mechanisms to update records in a batch format, and special code. Basically, I started building Flows to handle things that Process Builder cannot do… I think I bit off a bit more than I could chew. Starting with migrating a Process Builder (which presumably already works!) is a much more doable proposition. Luckily, I had mentors to help me when I was stuck. And if you’re reading this, YOU do TOO!
I wrote more about my experience with Flow:
- Going with the Flow (this addresses loops and screen flow elements and introducing a tiny snippet of code to select records from a List View)
We have some Record-Triggered Flows that were implemented thanks to consultants working on specific features, but they were not Flows that I had built on my own. I never much interacted with them until this project. So, I had built some tricky Screen Flows and that’s about it.
Official Step 1: Build in Sandbox
Like I mentioned previously, we were starting with an existing Process Builder (already unified by object) and with functionality that we wanted to keep and replicate (you should determine if the automation is still useful before you move it over!).
There are a LOT more features/functions in Flow, but in this section, I’m just going to outline the major parts of the PB and how each part mapped exactly to the Flow Builder layout.
#1 Tip: Use a good naming convention for your Flow parts. I like the one linked previously from Automation Champion.
#2 Tip: Work on familiarizing yourself with the concept of Bulkification (has nothing to do with lifting weights). I have struggled to internalize this concept and it may take a few different exposures and explanation styles to really get it.
#3 Tip: Never put a pink button (Get/Update/Create/Delete records) inside of an (orange) Loop.
This Flow has 2 paths (ding ding, this was a big learning for me – I hadn’t built multiple paths yet in a Flow!).
Scheduled Action (PB) = Scheduled Path (Flow)
The first Path handles all of the record/field updates (not in this screenshot). The second Path handles scheduled actions (Submit for Approval, in this case) (also not in this screenshot). You can have more than two paths in a Flow, just like you can have multiple Scheduled Action boxes in PB.
Notice the difference between the two paths (branches) in the Flow. In PB, you set a Schedule. In Flow, you create a Scheduled Path.
Blue “Nodes” (PB) = (orange) Decision Element (Flow)
Notice how Flow typically moves down the page VERTICALLY and PB typically moves across the page HORIZONTALLY. Interesting!
Notice how PB has a setting for “update all related records.” In Flow, you need more steps to collect related records, loop through them, and update them accordingly.
Record Updates (PB) = (orange) Assignment AND (pink) Update Element* (Flow)
This section shows how to update a regular, old field on the same Record that started the Process/Flow.
*For updating multiple records, you need to use Loops and Collection Variables, which I don’t cover in a lot of detail in this blog post.
Notice how a record would meet the Decision Criteria, get new field values assigned (temporarily), and then be Updated. In PB, you have two steps and in Flow, you have 3 steps (or more, lol).
Add Action > Submit for Approval Action (PB) = Action > (blue) Submit for Approval (Flow)
Works about the same way in both suites of automation!
The Whole Flow
Official Step 2: Test
Now that we have mapped everything into the Flow Builder canvas, it’s time to take it out for a test ride. The way I like to do this is a multi-step process.
- Use the Flow Debugger to trace a record through the Flow (check out this very useful Trailhead)
- Be creative and thorough with the scenarios you need to test (one for every “node”, check all relevant record types, check all relevant profiles, check all of the ways that records are potentially created (ie manual, form, API, code, other automated processes, etc), try to think of anything “weird” that can happen, try to create a record that does not meet the entry criteria and make sure the record is not updated by the Flow)
- Deactivate (for now) the Process Builder that the Flow is mimicking. Only the Flow should be active so that you know that it is the reason the desired outcome actually happened. (We almost forgot to do this… whoops!)
- Once you are through with the Flow Debugger, it’s time to create and edit records directly in the Sandbox to mimic common data entry protocols and look to make sure the fields/records that were supposed to be updated/created really are!
Now is your chance to officially get frustrated (or as my Pilates teacher says, “get fascinated!”) Some tests may not work. You will inevitably need to iterate and revise the Flow as you test and learn. I spent about 6 hours testing various versions of this Flow.
(Are you testing a scheduled action? The best way to check is to look at the Time-Based Workflow queue in the Setup menu!)
Official Step 3: Deploy
Once you are satisfied with your testing, it is time to move the whole shebang from your Sandbox to your main Salesforce (which we call Production). Guess what? This is always more complicated than I expect. Budget at least 2 hours…
- Create a Change Set in Sandbox, add Flow to it
- Upload to Production (wait a few mins)
- Validate in Production (wait a few mins)
- Deploy in Production (wait a few mins)
- Go to PB, deactivate!
- Go to Flow, activate!
- Test (again!)
For Scheduled Actions, you have to do some special steps… even though the PB has been deactivated, all of the future actions that the PB was supposed to do are still in the queue. I needed to delete all of these (connected to Old PB, still subject to the deactivated User problem).
(If you know of a better way to do this, I am open to suggestions! This is how I did it, and it was successful)
From a change management perspective, you may want only *new* records to go through your new Flow. In my situation, I actually wanted all of my open Payment records to go through the Flow. In order to do that, I created an “Update Helper” checkbox field on the Payment object. Then, I changed my Flow criteria for my Scheduled Path to look for “Update Helper = True.” Next, I used a bulk update to “poke” all of the records by checking off that box. I did this operation with an extremely small batch size (10) because I knew the Flow was going to do a lot of work in the background to run the Flow for each record. Finally, I changed the Flow back to its original criteria and cleared out the Update Helper field. When I checked the Time Based Workflow queue, I could see that all of my Payments were queued to be entered into Approval in their appointed month.
Yes, this was a pain in the butt. Yes, it’s March 1 and we got 143 payments entered into Approval with NO errors* 🙂
*there actually were some error alerts, but they were referencing Time Based Workflow entries that had been deleted… haven’t gotten to the bottom of that yet, but it looks like it did not lead to any real problems.
Official Step 4: Celebrate
I celebrated by making a post in a professional Slack group for other people in my field! I also made an announcement to my Admins Committee that everything went smoothly. This change should be absolutely imperceptible to 100% of people, but I still wanted my team to know that the transition was thoughtful and successful. Finally, I am writing this blog post! Writing helps me cement my learning, document my decisions, and help people in my community tackle similar problems.
I hope this blog post cleared up some common pain points about moving from PB to Flow! My suggestion – start with one Object. You GOT this!