Knowing how to work with data within a Salesforce Flow is fundamental. We're always working with data in some form or fashion so it's important that we understand these concepts. So what are all these data elements? Well, the easy answer is they are the pink ones. They allow us to create new records, update existing records, get or retrieve records, delete records, and recently added, roll back records.
We're going to look at all but the first three and then add in another element called an Assignment. Let's get started.
The Get records element is very similar to setting up List Views:
All Salesforce Flow elements require us to give them a name or Label. I recommend using a good naming convention. Mine are always prefaced with "get"; for example: "getAccount".
It's always a good idea to give every element a description, but I'll be honest, I don't often do it unless I'm doing something complex or odd.
Let's move on to the Object field. Start typing the object you want to retrieve data from. As you type, it will begin to filter the objects that match what you've typed. Salesforce made this super easy. Once you've selected the object, several new sections will appear. Let's talk through those.
I mentioned earlier that getting records in Flow is similar to creating a List View. The method used to filter the records is nearly identical. You select the field you want to filter on, select the operator, ie: equals, starts with, etc, then the value you wish to filter.
If this is a new concept, let's look at an example with my deck of cards. Let's say I wanted to only work with the cards with the number 10. Our field would be on the Card Number, the operator would be Equal, and our value would be 10. When we apply that filter, we'd end up with four cards, and all the other cards would be discarded.
The above example uses only one filter or Condition. However, we can add several more to be very granular in our request for data. When you need more than one condition, just click the Add Condition button, and a new line will appear. By default, each condition will be added to the prior Condition.
If you need a more complex query, you can customize the Condition Requirements to be "Any conditions Are Met (OR) or can set up your custom mix of ANDs and ORs. Be sure to carefully group your ANDs and ORs within parenthesis "(" ")" or you may not get the expected result.
If the order in which the records are returned matters, you can select a single field to sort on. Hopefully, someday, Salesforce will increase this to allow for multiple field sorting, but for now, we have one.
Our next section, How Many Records to Store, has two options. The element needs to know how many records you'd like it to return to the Flow. Return Only the First Record does exactly that. It will return only one record. Let's say you want the most recently modified Contact record where the Mailing State is Iowa. You'd add your Condition of Mailing State Equals Iowa, then set the Sort Order to Last Modified Date in Descending order. Only one record will be returned.
But what if you wanted all the Contacts from the state of Iowa? Then you'd change the How Many Records to Store to the All Records option.
This is a good place to introduce another concept called a Collection. A Collection is simply more than "one." This is important to understand. Remember in the first post of this series; we talked about variables? One of our variable types was a Record, and when we defined it, we had to indicate if it was for a single record or multiple records.
Flow, as with any programming code, is very literal. You cannot store multiple records in a single record variable. It would error, so Salesforce won't even let you. That's a whole other topic, so for now, just remember a Collection of Records is NOT the same as a single Record variable.
This section is interesting and can be confusing. It defines how you want the data to appear within the Flow. You have three options to choose from. So why would Salesforce give us three options? Good question, and it has to do with how much control you want to have.
If you want the easy option, choose the default selection, Automatically store all fields. Although less efficient, it is easy for those learning Flow. Basically, Salesforce does all the work for you. Why do I say it's less efficient? Let's go back to our example of Accounts from Iowa. In this option, I will get every field on the Account object regardless of if I need them or not. That can be a lot of extra resources for the Flow to manage if I only need the Account Name and ID.
Option number two is to Choose fields and let Salesforce do the rest. When selected, it opens up fields for selecting which fields you'd like to have returned to the Flow.
This is a nice option as it solves the problem identified with option one. Salesforce will handle all the Labeling associated with Getting Data.
Option three is the more advanced option. It's what I kindly refer to as the control freak's option. It's similar to option two, but you'll be able to control all the Labeling of variables.
I happen to fall into the control freak bucket, so this is often the choice I make. What can I say other than I really believe in naming conventions? This option allows me to use labels I'm comfortable with.
With that last section complete, we're ready to press the Done button as we've fully defined our Get Element. That was a lot but good job for making it through it!
Wait, Terry, you said "data elements are pink," but when I look at an Assignment, it's orange. You are correct! Assignments are orange. This post is about working with data. Not just performing database actions. Sometimes we have to manipulate or create new data, and one of the best ways to do that is with an Assignment.
Let's add an Assignment to our canvas by selecting it from the Logic section of elements.
As with every element, we first need to give it a name. The API Name will populate for us, so use that extra time to populate the Description field. This will help you and those after you understand why you're using the assignment. :).
The entire purpose of the Assignment is to assign values to variables. Why would you want want to do that? Let's go back to our deck of cards. I have a variety of cards in my hand. It's more than one card, so it would be a Collection. I want to know how many diamonds and how many hearts I have in my hand. In our head, we'd scan through the cards and quickly count the diamonds and hearts.
Flow does the same thing using a Loop. We'll talk more about Loops in my next post, but for now, a Loop will evaluate each card one at a time. We'll use a Decision to determine if the card is a diamond. If so, we'll use an Assignment to add 1 to a variable named varDiamondCount. The same Decision element can determine if the card is a heart. If so, an Assignment can add 1 to a variable we'll call varHeartsCount. If the card isn't either of these, then we'll move on to the next card.
Let's get back to the actual Assignment element. The screen starts us off with one set of assignment fields ready to go, so click into the Variable field, and you'll be greeted with every variable defined in your Flow. If the variable doesn't exist yet, then we can select New Resource and create one. In our card example above, let's say the current card is Hearts. Our Variable would be varHeartsCount, the Operator would be Add, and the Value would be the number 1.
After we've looped through all the cards in our hand, varHeartsCount and varDiamondCount will be set to the total number of hearts and diamonds in our hand. Now you can use those variables to display the total counts or save the totals to a record.
If you have more than one variable to set, simply click the Add Assignment button, and another row of variable/values will appear. Add as many as you need for your use case.
Here's another use case for an Assignment. Let's say you need a custom record Clone process. The variable within your Assignment would be defined as type Record. You'd then be able to set field values according to your custom requirements.
When updating existing records, we have two options.
The simplest is if what we need to update is defined as a Record variable and that record has its record ID assigned. In this case, leave the default setting of Use the IDs and all field values from a record or record collection. We can simply enter the sObject variable in the Record or Record Collection field and we're done.
I used a word you may not be familiar with: sObject. sObject is an old term that means Salesforce Object. When a variable is defined as a type Record, that's a sObject. That's why you'll see several of us old-timers preface our Record variable names with "so". A single Account record variable name might be named soAccount, whereas multiple Account records might be called soColAccount.
The second option is to Specify conditions to identify records, and set fields individually. This option would be used when we want to define our fields and their values all within the Update element. First, enter the name of the Object you want to update.
Because we're defining the record from scratch, we may not have a record ID, so we need to add a condition or filter. This is how you tell Salesforce which record(s) you want to update. For example, field BillingState equals the value of Iowa, and the field BillingCity equal to the value of Des Moines.
After we've defined the filter, we can Set Field Values. Let's assume we want to update the Account Industry to Insurance. We'd search for the Industry field and then in the Value field, select Insurance. If we need to set other fields, we can press the Add Field button.
Once all our Fields and Values are set, we press the Done button to close the Update element.
This may seem obvious, but the difference between the update element and the create element is that with the create element, there is no existing record. We're creating a brand new record.
Give the Create element a name and then choose How many records to Create: One or Multiple. Is it a single record (one) or a collection (multiple)?
If we're creating One record, then we'll need to select how our record was defined. The two options are: Use all values from a record or Use separate resources, and literal values.
The first option, Use all values from a record, frequently means we defined our record using an Assignment. We just need to add the Record variable to the Record field and we're done.
The second option, Use separate resources, and literal values, will let us choose the object type we want to create. Then a Field / Value set will open for us to define values to each field we want to populate.
When we choose to create Multiple records, we would have had to define a Record Collection variable and store all our values using an Assignment. Multiple records will only give you the option to point to a Record Collection variable we previously defined.
What's the Manually assign variables option we see when creating a single record? This opens up another variable field that is used to store the ID for the created record.
But do we get the record IDs when we Use all values from a record? The Manually assign variables checkbox isn't an option. Here the IDs are simply stored back in the Record variable used to create the records.
Let me explain. If our Record variable is called soAccount, then the ID will be stored in the soAccount's ID field (ex: soAccount.ID). If the Record variable is a collection, then the ID will be stored in the ID field for each record within the collection.
Now press the Done button, and you will have completed the Create Record element.
Hopefully, this simple post helped you understand how to work with records inside Flow. Just a quick reminder; use a good naming convention throughout your Flows, and it will help you keep track of all the variety of resources you create within a Flow.
In the next post, the deck of cards will be back out, and we'll use them to help explain Loops. Loops are powerful and are a critical element of Flows.
Be sure to watch the video presentation on YouTube. I hope you will Like, Subscribe, Follow, and Share my content with your friends and co-workers.