Meet Variables, Paths, and Loops

[Narrator] So you want to learn Salesforce Flow? Well, it's important to understand the concept of variables. Simply put, variables in flow are used when a value can change based on certain conditions. A variable is just a container that holds a piece of information. Every variable in flow has a name and a value. As you move through the flow, you can access the value in the variable and even change it. That's why it's called a variable.

Think of it like lunch. Your lunchbox is the variable. The name is My Lunch and the value is sandwich. On Monday, you use your lunchbox, the variable, to carry a sandwich. On Tuesday, you re-use the same lunchbox, the variable, to carry a slice of pizza. Variables, much like a lunchbox, can even be empty or null. Now that you get the general idea of a variable, let's get a sense of what a variable in flow does.

For example, a variable in flow can be called Contact ID. Let's say the value of the Contact ID variable is the ID of the primary contact on an account. The flow scans through all the contacts on the account object looking for certain features and concludes that someone else should be the primary contact. The flow then assigns the new contact's ID to the Contact ID variable. It's very important to know that this change is not actually saved in your Salesforce org yet. Variables are containers for information that are inside the flow. These changes aren't saved to your Salesforce org until you give it instructions to do so.

Congratulations! Understanding variables can be tricky. Remember, a variable contains information while inside the flow, the value of the variable can change, you have to take more steps before the flow makes any changes to the actual data in your org.

[Narrator] Welcome to today's lecture on lunch boxes. The first commercial lunchbox was invented in the 19th century. Just kidding. Well, kinda. This video is all about variables. The lunchbox is a flow builder. A variable is a container that holds a piece of information, much like a lunchbox holds different foods.

However, while the type of data in our flow lunchbox remains the same, the value of what's inside can change throughout the flow. A thermos is meant to hold liquids, right? Like that, a variable with a text data type holds text, and a variable with a number data type holds a number.

If you've built Salesforce fields, then you should be familiar with many of the choices for variable types, text, number, currency, date, date/time, pick list. But a few might be new to you. Boolean is used to store a true, false, or blank value. It's similar to a checkbox field, except that here blank does not equal false. Blank means null or nothing. Another variable type is Apex defined. This variable data type manipulates the complex data objects that are typically returned from Apex code or calls to web services. Once we choose our type of variable, we have the option to allow multiple values. This turns our variable into a collection variable.

That's a lot like getting a bigger lunchbox to hold lots of sandwiches. Our collection variable only holds a collection of the same type of variable. For example, number variables can only be with other numbers. And like sandwiches can only be in a collection with other sandwiches, contact records can only be in a collection with other contact records. We can't mix objects in a collection.

In conclusion, variable types are similar to field types on records. Any variable type can be in a collection of variables of that type. If your lunch box is a container to hold tacos, you're only eating tacos for lunch. And as usual, always test your flows in a sandbox org.

[Narrator] While we talk about trails a lot here at Salesforce, let's focus for a few minutes on paths, specifically scheduled paths. Use scheduled paths in record-triggered flows to schedule flow actions for the future rather than immediately.

Let's look at an example. When a lead record is created, our flow will fire. The flow is triggered by the creation of this record. Use a scheduled path to make something happen minutes, hours, or days in the future, like sending an email to a lead three days after their creation date. You're not just limited to scheduling based on created date. Scheduled paths can be based on any date or date/time field on the object, and they can fire on that date, after it, or even before it.

Let's say there's a record-triggered flow that sets a membership expiration date when a contact is created. In the same flow you can schedule an email reminder to be sent five days before that membership is said to expire. If you're familiar with workflow rules or process builder, scheduled paths are equivalent to time-triggered workflow rules or time-based actions in process builder.

Now, let's talk about two things that might look like scheduled paths, but aren't. The start element in a record-trigger flow offers an option to include a Run Asynchronously path to access an external system. You can ignore this until you need a more advanced flow. And don't be confused by scheduled triggered flows. This is a type of flow that can be scheduled to run once, daily, or weekly. For example, you can set up a scheduled triggered flow to run once a month, to mark any leads that haven't changed in that time as called.

To recap, use scheduled paths in record-triggered flows to automate steps taken any time after a flow is initially triggered. A record must be created or updated to set it on a scheduled path. Scheduled paths can be based on any date or date/time field on the object. And as always, be sure to test your flows in a sandbox first.

[Narrator] The topic of flow loops is complicated, but don't get thrown for a loop, all puns aside. Loops in flow builder look through a collection, like a list of records, and do something based on each record.

Flow loops are incredibly powerful, allowing you to create, update or delete hundreds of records in your database all at once. While loops in flow may sound complicated, the idea makes more sense when we apply it to a practical application.

So let's join Oscar for his turn to clean out the refrigerator at the end of the week. Oscar will take all of the steps of a flow loop, just with leftovers rather than Salesforce records. Here's a quick breakdown of how flow elements, actions that the flow can take, correlate with refrigerator clean up.

The first flow element we need is Get Records. We use criteria to determine which records we want to get. In this case, Oscar is getting all of the leftovers not labeled. Next, we add a Loop element. The flow will evaluate each record at a time as it goes through the loop. In our example, this means Oscar will examine each item one at a time. Next we will add in a decision element. Will we keep this leftover or throw it out? Decision elements are not required in Flow Loops but they make sense in this case. For records we want to update, we'll add in an Assignment element to indicate our intended changes, like updating a date field. For our example, Oscar decides to keep this item and adds a label with today's date to this item. We add a second Assignment element, which is like a container. We put the record in the container that we'll use to temporarily hold all the records we plan to keep. This is like Oscar putting all the leftovers to keep in a box. Now we've taken that first record through the loop and we start over with the next record.

Oscar examines the next item. After the decision element, we need to build an alternate path for the flow to take. What will Oscar do with leftovers he doesn't want to keep? Let's add another Assignment element. This time we'll use a container to hold all the records we plan to delete. Oscar's container for unwanted leftovers is his indoor compost bin. Then the loop starts over with the next item. And so on until all records have gone through the loop. After the Loop, we need to actually make changes to the database. Our box and compost bin are only temporarily holding our items.

Let's add an Update Records element to the flow to finalize our changes to the keep records. Remember, we added a date value to our keep items. Oscar puts his keep box back into his database fridge. Let's add a Delete Records element to get rid of records we don't want. Or in Oscar's case, the outdoor compost bin. Did you notice how Oscar took all the items out to the outdoor compost bin all at once instead of taking each piece one by one? That would have been a big waste of time. It's the same with Flows. You always want to keep your Data Elements, in this case, we used update and delete elements, outside of your loop. When you put a record in an assignment element during the loop, you're only indicating that you intend to update it after the loop, like putting it aside to deal with later. It's much more efficient to make all changes at once, like carrying all your compost outside in one container.

Congrats, you not only learned about flow loops, but you also helped Oscar efficiently clean out his refrigerator. Don't worry, Oscar will keep you in the loop next time he needs help.

[Narrator] So you have a problem in your Flow Builder automation that requires some troubleshooting. Well, I've got good news, Flow Builder comes with a built-in debug tool. Debugging helps you identify the problem and isolate the source, so you can then either correct the problem or determine a way to work around it. We know your automations are always set up perfectly and never break, so you don't need the debug tool. That's certainly not the case, even for the most experienced Flow Builder experts.

The Flow Builder debug tool is a must have for anyone building flows. When the debug tool in Flow Builder finishes, a breakdown of the result is displayed. Was the automation successful? Did it fail? Where did it fail? The result details will outline how the interview started, that is what triggered the flow, what record interactions happened, and if those actions were successful or not.

The Flow Builder debug tool is not only useful for troubleshooting, but also initial testing. Features include testing the automation before it goes into production. Designating a specific input variable during debug. Debugging different paths of the automation. Triggering a flow as though the record was created, updated or deleted. Running the automation as another user. And producing details of the debug and the path it took. Use the Flow Builder debug tool when creating a new automation or fixing an existing automation with issues.

Remember when debugging in Flow Builder that it actually interacts with the data in the org. This is why it's imperative to always debug a flow in a sandbox org. An incredibly useful feature to use when testing in your sandbox org is the rollback mode option. If you use rollback mode when you debug a flow, Flow Builder rolls back changes that the automation makes to the org after the automation finishes.

To recap, all new or updated Flow Builder automations should be tested with debug. Debug has numerous features, like designating input variables, revealing flow element outcomes, and executing automations as another user. Best practice is to debug in a sandbox org and use rollback mode.