Road blocks at every step of creating a streamlined inspection workflow...how?

[dolson_farmington]

Hi all--

I work for local government, where repeated inspections of static features are required (think storm ponds, sumps, construction sites, etc.). There hasn't been a step involved in creating a streamlined workflow for inspecting these assets that has worked as expected. 

For assets that require multiple inspections, a 1:M related table is the gold standard for keeping track of multiple reports on that single asset. However, this method has created a host of problems when trying to incorporate into any application. 

Firstly, a joined view layer is not supported in ArcGIS Enterprise Field Maps. None of the workarounds for this are time-sensitive (i.e. running a script to update the host layer periodically). If I have a team of staff out inspecting assets, they should be able to see in real time where inspections have already taken place so that work is not duplicated. This is currently not possible for assets that have information tracked from a related table. 

On top of that, photo attachments aren't inherited into a joined layer. So when I have staff conducting maintenance, there isn't a way to show the three key components of the initial inspection in one pop-up window: the location of the pond, the information collected for the inspection, and the photos taken on the inspection. Either the related table can be referenced (with no physical location associated), or the joined layer can be referenced (with no photos included). 

Lastly, URL parameters are limited. We are using automated emails to notify staff that and inspection has resulted in a maintenance request. In Instant Apps, you can only choose one layer to be the focus of the URL parameter, so a Storm Infrastructure maintenance tracking viewer, for example, can only reference one type of asset (ex. storm ponds), while other assets (ex. outfalls, catch basins with sumps) can not be referenced in a link the same way. 

What are folks doing to streamline inspection workflows? I'd like to be able to use Esri products for asset management, as it is one of the largest components of my organization's needs, but it doesn't seem to offer almost any straightforward way to accomplish seemingly basic processes. 

[ZachBodenner]

One thought I have for your first issue is to do some kind of symbology or filtering for assets that need inspections. You could use like a 'last inspected' date field and set a definition query to only show assets where the inspection is more than x days ago. Then, you could have an attribute rule that pushed the current date to that date field whenever a record is added to the table, thus "invisibling" your assets for that period of time you determined. That's if you're using references as opposed to hosted data of course. If you like, I can provide some code examples for how you might accomplish that.

Ultimately, using ESRI's ecosystem as a fully comprehensive asset management system will be the bane of your existence. It's great for a lot of things, but once you need to start assigning work orders, giving people lists of things to do, really relying on automated emails, etc, you are likely to find a totally unworkable road block somewhere. 

[DavidSolari]

This is a longstanding design quirk of ArcGIS workflows: if your data is too heavily normalized there's rarely a good way for users to edit it without diving in and out of endless popup chains. The best workaround my org's found is to store assets as a single feature class per type (or use subtypes if you have a bunch of similar types) then use Arcade expressions in the feature pop-ups to generate links to Survey123 which wrap around the other tables. By passing a unique ID for the asset (the GlobalID is a good choice) through the URL the new survey now has a link back to the asset. You can then let users work with a reasonably normalized table set by using repeats in the survey. Glue everything together with relationship classes and you've got something! You do have to train users to jump between both apps, there'll be some limitations viewing new data if they're offline, and you might still have limitations viewing attachments in Field Maps but it's about as good as you'll get for field work. If your org has some money burning a hole in their pocket you can use the JavaScript SDK to build custom web apps that can handle fancier data structures but if you want the built-in stuff you'll hit these limits often.

[AustinAverill]

@DavidSolari hit the nail on the head more or less. The most comprehensive way to address a standardized structure is through some sort of custom application using the SDK or just building some dynamic app utilizing the API. 

That being said, I think you are far from the ceiling of the tech you are currently attempting to leverage. For instance, your current situation seems addressed by the submission of an inspection record (child layer) being instantly relayed to the parent layer. While running periodic scripts certainly does not address this need, using webhooks would. This is basic functionality that is included with any featurelayer, you just need to set up something to handle the webhook (make.com, powerautomate, custom api, etc). 

In my org I am leveraging webhooks to trigger various actions, edits, feature creation, etc. based on records being edited, surveys being submitted from Survey123 etc. These are all instant on submission/edit, and for something like simple attribute editing between child and parent layers would take less than a second typically. 

[Joshua-Young]

What version of ArcGIS Enterprise are you on? Related table support has come a long way at 11.4 but still has limitations. Two recommendations that I have are:

1. Create the feature class, table, and relationship class in ArcGIS Pro and publish that to ArcGIS Enterprise.
2. Make sure to base the relationship on the feature class's GlobalID field and a GUID field in the table https://support.esri.com/en-us/knowledge-base/how-to-set-up-related-tables-in-arcgis-pro-for-use-in-...

If your data is stored in an Enterprise Geodatabase you can use attribute rules to pull the latest inspection info from the most recent inspection into the feature class without having users dig through popups.

If your data is stored in a hosted feature service, you could use webhooks and web tools to add the most recent inspection info to the feature layer but it is more work.