Automate This! — Karmel James’ ‘One Per Object’ Flow Design Pattern

Welcome to another “Automate This!” In this live-streamed video series, we cover all things automation, from use cases and best practices to showcasing solutions built by #AwesomeAdmin Trailblazers like you. With automation, you can remove manual tasks, drive efficiency, and eliminate friction and redundancy. In this episode, three community Flow experts showcase their record-triggered flow design patterns. This blog post covers the record-triggered flow Karmel James discussed during the episode.

What can I say? I’m picky when it comes to the configuration of flows. Let’s take a closer look at this flow that runs on the Opportunity object.

As with most companies that sell products, the Opportunity is a highly used object that will have multiple automations that need to run off of it. I like to start my record-triggered flows with a central Decision element. Instead of creating multiple flows for different automations, I tend to keep as many of those actions in a single flow. Keeping everything in a single flow can support future troubleshooting when I’m trying to figure out which automation ran incorrectly. With everything in one place, it becomes easier to debug. Don’t get me wrong, it can become a lot, but that’s what subflows are for too.

This single Decision element acts as the initial entry criteria. With adequate planning, different outcomes can all run through this single Decision and process the outcome before reaching an end or hitting another Decision.

My first Decision is related to what happens when an opportunity close date is changed. If the close date is changed multiple times, that can signal that the sale is not likely to take place. We take the current record’s count to add 1 to increase the count accordingly with a formula.

After that action is complete, the next Decision considers if, within that same edit, the stage was changed. If it was, our next step is to utilize the Get Records action to find all of the related opportunity products that were sold, so a renewal opportunity can be created along with a set of renewal products.

The first step is to create the renewal opportunity so it’s available later when we add the products. From a best practice standpoint, I would say an Assignment element and record variable should be used to store the new opportunity values to create the new record. But given that I’m only using this once, it’s much faster and easier to utilize the Create Record element rather than an extra step to reference the same values.

Using the Assign Manual Variables option in the Create Renewal Opportunity action, I can store the new Opportunity Record ID to reference it later in the loop.

The last step is to utilize a Loop element to run through each of the opportunity products sold. The Decision element is first within the loop to confirm whether or not the product is renewable. If it’s not, then the loop moves on to the next product in the list—best not to spend time on a record that doesn’t matter.

If the product is renewable, we continue with an Assignment element to set the values of the new opportunity product records. Using the values from the current opportunity product in the loop, it utilizes the Price, Quantity, and Product ID along with the Record ID of the newly created renewal Opportunity in the Assignment. This Assignment uses a record variable to store these values before it’s added to the collection, cleared, and used again for the next product. Unlike the step to create the renewal opportunity, I used an Assignment because I know I will be creating multiple of the same type of records vs. a singular one.

To maximize the flow’s resources, having a record collection variable that stores the sets of Opportunity Product records to be created means I avoid using a Create action within a loop. I want to avoid committing any hard database requests within the loop to conserve limits. #AwesomeAdmin.

After all of the products have been processed, we move on to the final step to create all of the renewal Opportunity Products in a single Create Records action using the same record collection utilized within the loop. Here we come full circle, where we can ask Salesforce to commit all the new records in one action as opposed to four to five times or an infinite number of times.

In comparison to very complex flows, I love this use case because it supports reducing the number of database hits (data elements of Get, Create, Update, or Delete Records) in the flow itself. To build a good flow, yes, it should mimic what a user would do by hand. To build a great flow, it looks for ways to reduce the number of times you ask Salesforce to take the same action. Loops and Assignments are great ways to reduce that number so at the end of all the logic you just have the Data elements. The way I like to think about limits and hard database actions is like running up the stairs. If, for each database action, you ask a person to run up the stairs with a single 1 pound bag, that can be tiring if you do it 50+ times. But if you ask that person to take five 1 pound bags at a time, they will still tire but not as fast. That same logic can be applied here to keep your users and the system running smoothly.

Resources

• Trailhead: Flow Builder
• Trailhead: Get Familiar with Flow
• Salesforce Admins Blog: Automate This! — Designing Record-Triggered Flows