Salesforce Variables in Flow. Why and How?
Hello from Belgium ! ‘WHY’ is it this way ?
The other day I was talking with colleagues that had to design flows and they asked me “why do we need to create variables all the time?”
To be honest, at first I did not quite get the question then I understood the gap!
Understand the basic logic of code
Yes, I started as a developer, thus I approach requirements as a developer, even if it is by creating a flow. At Salesforce the functionalities are created by … yes … Developers !
WHY: Behind flows, the salesforce platform compiler generates a code just like an APEX developer could create. Hence a flow design should happen like a good APEX class. As such, you should follow at least the basic practices of code :
- Group your DML (create/update/delete) at the end of the flow
- Create collections of Objects and commit all at once in a DML (don’t create in loops etc.)
- Perform SOQL with all relevant fields once (don’t loop)
WHY : Well as I stated before, behind the scenes the code is generated and is subject to the same rules as all other code : the governor limits
This means that in your mind, when you create your flow you need to anticipate what you’ll need, what operation you’ll perform and what are the steps required.
What about variable in flows?
You need to see variable in flows as ways to store intermediate steps of your work. A little box where you place some elements you’ll need for later. Each box has a little sticker that explains what is inside and a unique name so you’ll be able to find the box back.
An example ? You want to change the status all Case records that have been updated more than 2 years ago to old
- Create a Collection variable of Object for Case
= The box sticker explains that it is the collection of Cases. The name on the box is your API name. - Find all records that matches the criteria and store them in your collection (box)
- Loop to your collection
= For each element that are in your Collection, take one, put it in another box that only contains one element. - Update that one element
= Change the value status to old for the element in the box - Loop next element
= Put back the recently updated element back in the big box and take one that you did not update yet in your single record box - When last item in collection loop has been updated proceed
= In your box, all cases now have status old - Commit to Database with Update collection (DML)
= apply your changes
What’s nice with this concept of variables is that you can use elements during computation. While you did not perform the DML, validation rules, mandatory fields etc. are not enforced.
WHY: Please take time here. As we only do the DML at the end, this allows us to do things one at the time. Even if at some point we know that what we do would not pass validation rules, we are still allowed to do it as long as DML is not performed.
An example ?
Assume you want to duplicate all Order Products for one order to have them under another newly created order.
As best practice suggest, you’ll first query all Order Products of your existing order, generate new Order Products in a collection with the link to the products. But they will miss their parent order as it does not exist yet ! If we would call Create record for the Order Products, we would have an error. However as this is a variable, it does not matter. As long as we don’t DML things can continue. You would thus then create and DML the Order, retrieve its ID and assign it to all your Order Products in you collection. You’ll then safely create (DML) based on your Order Products collection.
Long Story Short
In conclusion, variable are temporary boxes that stores elements while you are still working on them. They only enforce type (sticker description) but not the Database insertion criterias (require fields, validation rules, …)
