Earlier in this series, we examined what can be done in a tight, master-detail relationship in order to change the status of a parent record when all related records meet a certain criteria. Now we’ll take a look at a scenario in which the two objects in question are related via lookup and therefore roll-up summary fields (as helper fields) are not an option.
NOTE: This rundown assumes solid familiarity with Flow Builder and will not suffice as a beginner’s tutorial on Flow. Check out Trailhead to get started if you’ve never used Flow.
The Scenario
We have two objects that need to exist independently of one another: Equipment Requests and Equipment Inventory. The two objects are related to each other via a lookup relationship field created on the child object (Equipment Inventory), so multiple pieces of equipment can be added to an Equipment Request and they can be viewed in a related list on the Equipment Request record.
Since Equipment Inventory records represent actual pieces of medical equipment sitting in the warehouse, they need to be able to exist before being associated with an Equipment Request. i.e. The relationship field needs to be optional, not required. This is why a master-detail relationship won’t work and why we’re using a lookup relationship.
How to
What we’ll have to do for this use case is leverage Process Builder and an auto-launched Flow to enforce an update to our parent record, Equipment Request, when all our child records match our criteria.
Flow
Flow is really the meat and bones of this automation, while Process Builder will only be the gatekeeper that tells our Flow to run. So let’s start with our Flow.
We’ll plan to…
- Run the Flow when a child record is updated to match our criteria (Process Builder)
- Then our Flow will be setup to go fetch all child records related to the parent record of the child record that started the Process
This is an important junction and the reason why we’ll setup the Flow first. Our Flow must have a variable defined into which we can pass the Record Id of the child record that started the Process. With that Record Id, we can ask our flow to find the parent record and then find the rest of the related child records.
With our entry variable ready to go, the first step of the Flow is a “Get Records” element running on Equipment Inventory in order to fetch the record that kicked off the process. To find that record and make it available for use in our Flow, we simply define the filter criteria in the Get Records element so that Id equals our recordId variable.
Then the rest of the flow practically writes itself! Follow these steps:
- From your first Get Records element, branch another Get Records element. This one will run on our parent object (Equipment Requests) and will fetch the record that matches the relationship field on the Equipment Inventory record that started the process.
- Then we’ll insert a third Get Records element that fetches all the child records related to our parent record (i.e. whose relationship field contains the Id of our parent record).
- Define an Assignment element that counts the total number of related (child) records and assigns that number to a variable. Do this by using the “Equals Count” operator and use your collection variable for the “Value”.
- Next, repeat step #2 & #3 but this time define your Get Records element to fetch only the child records whose status is “Approved” and use another Assignment element to count those records.
- Lastly, use a Decision element to compare the value of your two different “count variables” and if the count of approved Equipment Items equals the total count of Equipment Items related to the parent record, then assign an updated status to the parent record.
- Don’t forget to Update the parent record!
Bonus: We could also add a branch to the Flow in order to handle a scenario in which some but not all of the pieces of equipment are approved for distribution. In this case, we could ask the Flow to update the status of the parent record to something like “In Progress” or “Working”. In this manner, as soon as the first child record is changed to “Approved”, the parent record’s status (Equipment Request) could be updated from “New” to “Working”.
Process Builder
Telling our auto-launched Flow when to fire, our process will simply…
- Run on the child record (Equipment Inventory) so that it can…
- Check whether the Equipment Inventory record’s Status field has changed and…
- Check whether the Equipment Inventory record’s Status field has changed to “Approved”
- If so, it will launch our Flow!
Comments encouraged!
Was this helpful? Or have you solved this use case in a different manner? I’d love to hear about it! Please share your comments below.
Orgs That Overcome 