Challenge
When creating an asset audit for a location, the OOB behavior looks for assets that are present specifically on the location defined.
This can be problematic if a customer wants to schedule an audit for a floor with assets that can be located in the floor itself − i.e : the corridor − but also in different rooms of the floor. Because of the default behavior, there is no lookup for assets that are located in the rooms of the selected floor.
Solution
The proposition here is to create as many audit records as necessary by making an audit record per locations linked to the floor in a recursive manner. In this way, if a floor has 2 rooms or 500 rooms it will create all of them regardless.
The logic is as follow, we want to have all asset audit record created to be linked together. We’ll use a catalog item to create a request and specify the top location we want to audit − e.g : a floor or a building − and we will have a flow that will orchestrate the creation of all the needed asset audit records for all the locations that are beneath this top location we selected.
All the asset audit records will be linked to a catalog task. In this way, we can implement a mechanism to close the task when all sibling asset audit records are closed.
We must however be sure that all asset audit records are created in parallel and can be worked on independently.
Important assumption
This solution assumes that locations data is correctly structured ; ideally with location types defined. The most important point is that we have a structure where buildings are linked to other locations – like “floors” – who themselves are linked to other locations – like “rooms”.
Creating catalog item to schedule asset audits
We first create a catalog item. The bare minimum is to set the location where the audit is to take place, who will do it, and when.
An exemple of the catalog item is as follow :
Create custom field on Asset Audit table
The purpose of the field is to link catalog tasks with asset audits.
The screenshot shows a reference field that points to the task table with a reference qualifier that segregates on records that are only catalog tasks. We can of course simply create a reference field pointing to catalog task instead. The choice made here is to leave the door open if we ever later on need to link the asset audit record to something else then a catalog task, just in case.
Flows
We’ll leverage flows to orchestrate everything. First, we will create a subflow simply for the creation of asset audits but also to close the catalog task that we created.
Subflow : create asset audit record
Important comments
- When creating the asset audit record, don’t forget to set type to location
- The wait for condition action allows us to pause the flow. This way the main flow can continue to loop and call the subflow multiple times, and at the mean time all asset audit tasks can run in parallel at their own pace.
- When the subflow will be called, it is necessary that the field wait for completion to *not* be ticked.
- The purpose of the final steps is to verify where we are with all the asset audit records. The if test condition simply verifies if the count of records looked up is 0 or not ; and if it is the test condition is true. If the current asset audit record we close is the last one, in this case, we can assume asset audit for the location is finished and we can close the parent catalog task.
Main flow
The main flow is a bit straight forward. On picture is worth a thousand words :
Important comment
- Retrieving the location must be based on the full name of location.
Because we select the highest location level in the hierarchy and we know the hierarchy structure is correct. We can consider that we want to have all the locations who’s full name *starts with* the full name of the location selected at the catalog item level. - As said previously, the custom subflow we created earlier must we invoked by *wait for completion* must be set to false. This allows the flow to continue create all the necessary audit records in parallel
This is it!
That’s it ! The last thing you need to do is to call the flow in the catalog item created and you can now create asset audits recursively starting from a floor or a building or higher ; but beware of limitation, see below.
There can be ways to extend this, for example adding an approval step after all the audits are done or simply by adding a related list in the catalog tasks to show all asset audits that are linked to the catalog task, etc.
Known limitations
We are restricted with the flow’s limitation concerning the number of records a look up action can retrieve or the number of iteration we can go through in a loop, which is 1000 records.
I would expect that in usual cases that doesn’t happen often in real life.
In cases it does happen, the workaround would be to divide in multiple requests. For example, if we want to do an audit on a whole building with multiple floors. Instead of choosing the building as the main location, we would select the floor and create a single request per floor.
