Inspection Workflows with Utility Network and Field Maps

[kvincent]

Hello everyone,

What are your workflows for tracking inspections within the Utility Network? I'm trying to create a map to be used in Field Maps to track Hydrant Painting. Right now, I have a "Hydrant Painting" table related to our Water UN. In the related table, I have a dropdown to select Painting Phase. Ideally, I would like to symbolize off of Painting Phase, so the field crews can keep track of their progress. However, since we cannot symbolize off of a related table, I'm stumped on how the field crews can use this app to track progress. To further this, I don't want the inspections written directly to the UN because of all the different types of inspections we conduct. I don't want the attribute table getting overloaded, so a related tables seems like the best way to stay organized. I just can't figure out how to visualize status for the project. We are running Utility Network in Enterprise 11.5.

Any thoughts or suggestions would be greatly appreciated! Thank you.

[kvincent]

Thanks, @wesztt. I like that approach. You still have the related table to store all the inspection records, but just one field in the UN so the attribute table doesn't get too overloaded. I think something like this could work for us. If you could share the Arcade, that would be great!

[wesztt]

Sure thing! The calculation rule should be applied to the related table with insert as the trigger. This has worked great for the Yes/No or Complete/Incomplete scenario, but I'm not sure how well it would translate to a more complex symbology with multiple attribute values.

// Get related parent feature
var parentTable = FeatureSetByRelationshipName($feature, "RELATIONSHIP_NAME", ['STATUS_FIELD'], false);
var parentFeature = First(parentTable);

// Abort if no parent found
if (parentFeature == null) return{};

// Return edit dictionary to update parent
return {
"edit": [{
"className": "PARENT_CLASS",
"updates": [{
'objectID': parentFeature.OBJECTID,
"attributes": {"STATUS_FIELD": "STATUS_VALUE"} // Updates field in feature class
}]
}]
};

[kvincent]

Thank you!

[RobertKrisher]

Is there a reason why you need to put it on the hydrant itself instead of using a separate point class that represents the inspections? If you are setting/updating a flag on the hydrant (or any other feature) that represents its inspection status you're going to need to push multiple updates to each of those features every year (resetting the flag saying it needs to be inspecting, marking the feature as inspected, then updating the last inspected date). Because the UN data is versioned, all these edits are tracked and archived forever. A more sustainable approach for inspection is to manage the history, status, etc using separate tables. Not just for hydrants, but for any kind of asset you are performing preventative maintenance/inspections on (valves, pump, etc).

It also solve the problem of what to do when a hydrant is abandoned or removed and you don't want to lose the history of the asset for liability reasons.

[kvincent]

Sorry, I should have been more clear. We don't want the data on the hydrant itself, it's just a matter of finding the right process combination to get that symbology to update for inspection tracking purposes, especially since we could have multiple types of inspections happening at once (or at least each year), we need a way to keep it all organized - for example, hydrant painting and hydrant flushing. I just don't want to have to export a snapshot in time dataset, but I think I follow more what you're saying about the separate feature class and how that is preventable. Thank you!