This is for you if you’re used to an automation world of Workflow Rules and Process Builders and you’re trying to get into flows, but just can’t get the hang of it.
Flows are different in that they are closer to development than they are to configuration. Where Workflow Rules and Process Builders have an assumed context (such as Account created), flows have less of this context and the context really needs to be created by the designer. While this makes Flows more complicated, it also makes them far more flexible. One of the most obvious things is that flows allow you to create branching logical paths - something you can’t do in Workflow Rules or Process builder (though it was a step closer). Oftentimes, as builders, we are split between great analytics and great usability. The reason I like screen flows best is because of their ability to bridge the gap between taxing data entry processes and robust analytics using guided user experiences.
One of things I’ve heard over and over again is that people don’t understand how to translate the data captured from the fields on a screen flow, into data that is saved back to a record. Or, conversely how to get record data onto a flow screen in the first place. This is where understanding the context comes into play. If we are designing a screen flow for processing data on a given record that will be launched from a record page, we need a way to inform the flow of that context. Think of the flow as an outside system that needs to communicate back and forth with your Salesforce environment. It needs to get information from the database, perform some work or logic, and then send some information back to the database. What it does on screen is decoupled from what it does behind the scenes whereas the old tools are tightly coupled to a specific record.
So how does this work in reality? We do this by allowing the flow to receive the record Id. So, we create a resource (a variable) in our flow to hold that record Id. We also need to make sure that external sources are allowed to pass that information into that variable. To accomplish this, do as follows:
- Add a new Resource to your flow
- ~Select “Variable” for the Resource Type
- ~Name it “recordId” (use this exact name here, it will save you some time later as it's something that Salesforce specifically recognizes for holding record Ids).
- ~The Data Type will be “Text” (Ids are really just text strings)
- ~Check “Available for Input” - this is what allows external sources to access this variable and pass the record Id into the flow.
- Add an element to “Get Records”. Remember we just have the record Id at this point, we don't have anything else, so we need to query it (get it).
- ~Give it a recognizable name for the flow in the label such as “Get Account”
- ~Select the object that you are getting - this should be the object for the record you are getting.
- ~~Remember the flow does not know your intentions or any context. You can hypothetically have an Account Id and use it to get contacts here. But for now, we’ll just focus on the record from the page we are working on.
- ~For the filters specify Id for the field, and use your “recordId” variable as the value. We’re telling the flow to fetch the Account whose Id matches the record Id given to us.
- ~Store only the first record and automatically store all fields.
- Once you add your flow to a record page, you will see you input variables waiting to be populated:
Now we have the record we care about in its entirety and can access its data from within the flow. This is what we used to take for granted in Workflow Rules and Process Builders - the record was assumed to be there whereas here there are no assumptions about what the flow is working on. You must first get the information and then you can work on it. The advantage is that we can store all these other variables and processes in the flow that only exist while the flow is running - they don’t need to take up field space in your objects just to support a run-time process. Every field that you add to your flow screens now becomes a new variable that does not necessarily have anything to do with your record. These fields belong to the flow itself, not to the object you are working with. You can use the object you are working with to prepopulate values into those fields but they are not automatically bound. The same will apply to saving a record. Using variables and data in your flow you can populate the fields of an update element to save information back to Salesforce.
Thinking about what’s happening in your flow as separate from what’s happening in your database may help you get over the hump of working with flows when you're so used to working with the legacy configuration automation tools. You may want to take a look at record-triggered flows to start as they are more closely related to the older automation suite in terms of access to the record because it’s passed in its entirety to those flows but still have the advantages of building multiple logic paths.
Ari Leeds
