Different capabilities on Related Feature Services?

[AndrewHargreaves2]

Hello,

Is it possible to set differing capabilities at the feature service ADMIN level on RELATED feature services? For example can the parent feature service be set to not allow edits, but a related child (tabular) feature service be set to allow edits?

I am able to access the Layer definition for my hosted feature service through the below:

https://services1.arcgis.com/xxxxxxx/ArcGIS/rest/admin/services/MyServiceName/FeatureServer/0/update...

Here i edit the capabilities from:

"capabilities" : "Create,Delete,Query,Update,Editing,Sync,ChangeTracking", 

To:

  "capabilities" : "Create,Delete,Query", 

I set the lastEditDate to "" as described by Jake Skinner and Kelly Gerrow here. I get no errors, but the service definition fails to update.

Thanks

[RussRoberts]

The feature service will have the same editing capabilities on all layers within the service so parent and children related layers will have the same editing support. If you want to restrict the editing of the parent in a web map and have the children editable then you can disable editing on the parent layer in the web map which in the case of Map Viewer and Collector for example will honor this setting. The parent layer will be set as view-only and the child layer will then support whatever the set feature service capability is. 

[AndrewHargreaves2]

Thanks Russell Roberts‌ for the reply, however, accessing the Feature Service via a webmap isn't really want I want. The proposed workflow is:

• customer publishes feature service of assets and related inspection table
• shares with me through secure group in AGO
• I perform asset inspections using Survey123 with results going into related table

The customer is nervous about sharing their production Feature Service of their assets with editing enabled. I guess best practices dictates that really their production datasets should never be editable, and only copies/replicas are used in editing workflows, even if that's just related tables. Would you agree?

[RussRoberts]

In this case you would want the user to provide an editable version to work against and use this in survey and only expose the inspection table in the survey. Then merge those inspections into the production case after they have been reviewed.