Expand variety of feature service editing options in AGOL to accommodate new Collector capabilities; Allow feature services to be editable in Collector, while preventing accidental movement of a GPS'd features
I work for a water company, and we recently completed our winter hydrant inspections! The Collector app empowered us to log and store all of our maintenance duties performed at each hydrant (painting, inspection, flushing, etc.) in a related table, as well as collect information about changes to core data regarding hydrants, AND to symbolize our data with a custom symbol based on an attribute stored in the feature service. Many thanks ESRI!
Right now when sharing a shapefile as a Service to AGOL - under Feature Access - we are allowed to Create, Delete, Querey, Sync, and Update. When publishing a relationship we must select all 5 in order to allow for the functionality we need to meet Collector's relationship class requirements, and to see that pivotal "Add New" button at the bottom of the primary pop-up. If you try to select "Update feature attributes only" in the editing section (see picture below) you can no longer add records to your related table in Collector. The last idea that I logged entitled: "Create new related records WITHOUT giving the option to create new features in Collector", spoke to the fact that these maps now automatically offer the option to "Create New" upon opening the collector app. In this case (with permanent, visible infrastructure), this is unnecessary and also not entirely useful due to data accuracy requirements that we follow here.
ANOTHER issue that we found with the current utility of the editing options that must be turned on in order for related table workflow to function correctly, is that our operators were accidentally moving our hydrants from their original, GPS'd location. Because we were asking our field operators to verify our core GIS data behind the hydrants (such as cast date, or model), I created a simple Yes/ No field that would tell me if they changed any of our core data, followed by a status field that changed the associated symbol based on work being required which requires editing the layer itself, not just the related table. After creating a new related record, they would come to the primary pop-up, compare our GIS data on that hydrant to the real-world conditions, tell me if they did end up changing any of that data (See Red box below), and then change our "Hydrant Inspection Status" field immediately below that from "Inspection Required" to indicate that inspection had been completed or that there were maintenance duties to perform (See Green box below):
HOWEVER, when you decide to edit a feature's attributes - because their X, Y values are also an attribute - you can accidentally end up moving the hydrant away from its real location if you tap on the map screen instead of the "Done" check mark in the upper left-hand corner, which has happened to us a lot. While this is more frustrating than anything else, we were still able to a) tell when a hydrant went missing (based on ID labels and location markers I integrated into the basemap; See below), b) locate hydrants even if they moved away from where they should be by making the map searchable (via their unique, internal ID field), and c) place them back on their hydrant branch using Collector's precise placement utility (press and hold on screen where you want to move your currently editable feature).
CONCLUSION (tl;dr): Ultimately I think the request I am trying to make here is that the Editing options under the Properties section of a feature service needs to be made slightly more dynamic to accommodate for the new offerings that ESRI has given us with Collector. How that needs to be done I shall leave in the capable hands of the experts 😉
