I’m not a huge reader, I’ll freely admit that. I much prefer visual forms of storytelling. On the odd occasion that I do read, one of my biggest pet peeves is when the plot is building, the tension is high and then the author decides to take a massive detour to fill in a bit of backstory.
Anyway, here’s a background of Flow basics…
Flow University
Most if not all computer programs work on three basic parts. You have an input, a process and an output. As a Flow is essentially a program you build with a drag and drop interface, it also follows this pattern. You want to create a record? You’ll need some inputs to populate the fields, the record will be created (process) and then the ID will be returned as your output.
The Flow platform has a number of ready to use record based processes that are fairly simple to get set up.
- Create Record
- Update Record
- Get Records – While the other three processes are obvious in their name, this one finds one or many records based on a criteria
- Delete Records
Although it’s not immediately obvious, you can also fire up Quick Actions, execute invokable Apex, submit records for approval and send email alerts. These sit behind the Action element. Under Interaction, Screen and Subflow also join Action. Screen lets you build a page to take inputs from the user and display information or results of a process. If you’re keen on reusability, Subflow is a handy element that will let you call a Flow from within another Flow. I like to call it Flowception – and if you don’t, we can’t be friends.
The final section of elements is titled Logic. Here we have some basic but vitally important data operations. Assignment lets you set a single variable or build up a collection (more on these later). Decision, as you might assume, allows you to evaluate a condition and then go down one of several paths depending on the outcome. Think of it like a choose your own adventure book. Finally, we have Loop, which is very handy when we have a bucket of records that we need to cycle through.
On the Manager tab, we have all of our resources. These resources represent data that we can use within our Flow.
For example, if we use Get Record to find a Case, we would then store the Case record ID in a variable. We can also store a group of Case IDs if we were to search for all records against a particular account. Within Flow, this group is called a collection. If we were to expand on that particular example and configure the Flow to update the all Cases it finds, it may look like this.
This is an incredibly simplified version of the process and would kill your governor limits if you tried to update too many records at once. There is a way to bulkify this operation and reduce the risk, but that’s a conversation for another day – it would look a little like this though.
If you can understand all of that, you can consider yourself a Flow expert and you’ll be ready for the next part of tutorial.