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

03-07-2016 06:17 AM
Status: Open
New Contributor III

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 😉

That second picture is hard to see, so I broke it up into two here:



We do not wish for our inspectors to create new features.  Just new inspections.  However, the likelihood of them creating new features is very high.  This is because as soon as they open a Collector map, the feature create menu is staring right at them.   The current situation is really risky.


I'd like to toss in a thought on this. Despite the December 2017 updates allowing for more granular permissions, which is nice, this workflow is still out of reach. Generally, it seems to boil down to a workflow of: permanent asset status tracking with related inspection logging (1-M relationship). In my current case, the permanent assets are parcels. Our inspection logs are attempts at collecting a survey in a related table. They are contained in a single hosted feature service on AGOL. They are used in offline maps.

I certainly don't want our field team to be able to add, delete, or edit the geometry for the parcels. They should have these capabilities for the attempts log table (well, just edit, since there's no geometry).

I can avoid the deletion issue with the new permissions settings (using Add and update features instead of Add, update, and delete features). The delete icon is still present in the map, but I see a Valid Polygon Required error if I try to use it and submit my changes. So, at least it can't be deleted, but I could see confusion if it's accidentally used.

I can avoid the geometry edits by updating the definition directly via the "allowGeometryUpdates" : false, setting for the layer containing the parcels. This works perfectly well, but isn't shown on the details page as an option.

I can't avoid the add problem. Without add, new attempts can't be added to the related table. I can remove Create from the "capabilities" list in the definition on the parcel layer, but when submitting the updated definition Create is also removed from the related table. That appears to be the same as the Update attributes only option on the details page.

It almost feels like there should be an advanced edit permissions option, where each layer in a feature service can have its own editing permissions set. The fact that updating a service definition where the first layer doesn't have Create capabilities and the second layer (table) does results in neither having Create implies to me that maybe there's an underlying reason that the layers maybe can't have different capabilities. Not sure though.

Another option I could see working is allowing symbology to be set according to a related feature's/table's attribute value. That would potentially eliminate the need to track the status of the permanent asset in an attribute value of its own, and instead symbolize that status directly from the related value. I can see how that could be complicated (which inspection/attempt do you base the style on? The "first" one based on the sort options you choose under Show related data?).