Prevent batch updates of hosted feature layers

[ColinCampbell1]

I'm not sure if this is exactly the right place to post this, but I wondered if anyone know of anyway to prevent the batch updating of data within hosted feature layers by things like ArcGIS Pro and the calculate field capability in ArcGIS Online?

Our use case is that we have a number of mobile data collection workflows where staff at 100-200 different sites submit data for their particular site.  The workflows involve multiple Field Maps, Survey123 and Quick Capture setups and numerous feature layers. The permissions on the layers allow each user to see and edit any record within the layer.  For the mobile side of this process everything works fine, but there is a risk that a user may open one of the layers in something like ArcGIS Pro and carry out a process like an 'update column' that accidentally edits large numbers of records for multiple/all sites (and that we can't undo it when this happens).

Is there a way to prevent this?  Or does anyone have experience of possible approaches that might mitigate the risks/impacts?

We can't alter the settings on each of the layers so that users can only edit records they have created as staff at the same site need to edit each others records.  We've thought about creating site-specific views of the layers and controlling access through site-specific groups, but the overhead of managing these and the different versions feels too great - unless people know of ways to automate the setup and management of these easily. Keeping in mind that we may need to update the structure of the layers and any associated maps/app setups as time goes by.

Any thoughts/suggestions would be hugely appreciated.

Colin 

[AbdiHassan]

Yeah views would be the best option especially for those using Pro and don't give anyone access to the master feature service. You can alter the schema with views but you do need to turn on those fields for each view so automating with python or FME would save you a lot of time. How many views are you thinking of having and what do you mean update the structure, is it adding/deleting fields or adding layers/tables or removing layers/tables?

[ColinCampbell1]

I think if we go down the view route (which we may do) it could be a case that one data collection process would require a different view on the core feature service for each site.  So instead of having one web map/Field Map that everyone used, we'd have to have 100-200 views with their own site specific web maps (and a user group for each site).  For us to be able to support that it'd definitely need to be scripted.

In terms of updating things, it's a bit of an unknown.  It could be adding fields or layers, but it might also be changing cosmetic stuff like styling and popups.  So there's a question about how feasible it is to update all the web maps and views at the same time and if everything could be scripted.  That's also just for one process so we'd likely need to do a similar thing for a number of different ones.

I suspect we need to try it out and see how far we can get with it. 

[EmilyGeo · Accepted solution]

Hi @ColinCampbell1, 

I understand your concerns. Its important to ensure that the field workers are assigned the proper user types and roles, which can help you maintain data integrity.  For example,

1. To calculate fields in Map Viewer, one must be either the data owner or an administrator in the organization. 

2. To calculate fields in ArcGIS Pro, one must have access to ArcGIS Pro. 

You mention that you have up to 200 users. It seems unlikely that each of them is an administrator, data owner, or Pro user. 

While views can be very useful, the use of a view may not prevent batch updating columns by users with the proper permissions. Therefore, ensuring that each user is assigned the appropriate user type and role is essential to mitigate these risks. 

[ColinCampbell1]

Hi @EmilyGeo,

Many thanks for replying. I didn't know about needing owner or administrator permissions to be able to calculate fields in AGOL so that would definitely solve that.  None of our users would have those rights in these instances.

Unfortunately (in this case at least) all of our users are either Creator or Professional Plus so they all do potentially have access to Pro in one form or another. The majority of the people in question won't use Pro, but a relatively large proportion do/will and it's them that we're trying to put protections in place for.

We're looking at how we discourage use of these layers in Pro (e.g. training and naming conventions), but that only goes so far. It feels like our best options at the moment are:

1) Use views for each site so that any accidental batch updates only affect the data for that site and not others.  We could then restore the data from a periodic backup and this process would be simpler as it relates to only a subset of the data.  The issue would also be the fault of the site involved, so easier to manage.

2) We don't use views but instead increase the frequency of our backups and how long they are kept for.  We also put in place monitoring/reporting to try and detect any batch update events.

It feels like 1) comes with significant maintenance overheads and 2) could get quite complicated when trying to restore things.

Am I right in saying there aren't any user role permissions or other settings that could manage the Pro side of this?

[EmilyGeo]

Yes, it sounds like you are on the right track. Leveraging the use of hosted feature layer views, setting proper permissions, and backing up the data, along with user training should go a long way to help ensure the integrity of your data.