Allow feature services with joined hosted feature layer views to have the data schema updated without removing the view

[Philip_Ohlinger]

Currently, if you have a joined hosted feature layer view  setup for a feature layer, you cannot edit the data schema of the layer in ArcGIS Online. This means you cannot add or remove fields, or alter the domains for the features unless you remove the view. This is extremely cumbersome, as we are using the joined hosted feature layer views for many of our features, but also need to periodically make changes to the data schema.

Please allow joined hosted feature layer views to be used while also allowing changes to the data schema of the features. This would save us so much time not having to continually delete and recreate the views.

[WillyG]

Thank you @EricaNova  that's great. The steps you have taken are really clearly laid out.  I'd like to try this on a proof of concept I have time. My main concern is that this could cause issues with sync enabled hosted feature services. If it can be done by  editing the JSON then I'm sure ESRI can build an 'update Joined view layer' UI 

The fact it can be done in the JSON should not be a substitute for a UI. Can someone from ESRI please give an update when we are going to have the ability to update the schema on source layers as stated that we would here (June 2023 ArcGIS online release) When will we see this on the road map?

if there is a technical explanation for not enabling this then please tell us why.

[csambol_cityofguelph]

I have also run into this issue as I have many views/maps created for a Citizen Problem Reporter implementation.  I have deleted the join views to which should have allowed me to add a field in the main hosted layer but it does not.  I have looked at the JSON and there is nothing there for the "editing" items in the previous post or "schemaLock" found in another post.  I need to add a new field to the main data to support the users but cannot determine why it is still locked as the main views should not have an impact on this, as well as if there is a tool to find the layer which may be causing the lock.  Looking for any assistance and I agree with everything that there should be a UI tool to accomplish this as Esri is promoting this option but we cannot break/delete views all the time to add fields for solutions that are in use.  Any assistance would be appreciated and I have also submitted a support ticket.

[Katie_Macintyre_Atmos]

Agree this is a massive limitation, especially when coupled with the functionality limitations in experience builder which mean you effectively have to recreate everything if you replace a layer in a web map. 

We have an EB app which allows our surveyors to see bird data, which has been joined to a table so they can filter by designation status. We need to add a field to the bird data layers which now means deleting 7 view layers, recreating them, replacing them all on the web map, and reconfiguring 18 widgets in the EB app. We would need to do all of this each time we needed to add a field to the dataset or update a domain value. 

At the very least there should be a warning when creating joined view layers that the schema for both datasets will be locked and updates to fields and domains will result in a lot of extra work.

[ScottKiley]

I first want to to say that I 100% agree that this needs to be implemented. We have implemented some workarounds that lessen the work required when needing to make a schema change on data that partakes in a joined view that @Katie_Macintyre_Atmos and others on this post have identified.

I fully understand that workarounds shouldn't be required for something so fundamental to utilizing this platform, but here are those workarounds.

1. Add a joined view to a web-map.
2. Do a save-as on the joined view layer to create a secondary item referencing the joined view.
3. When you need to make a schema change to feature services taking part int the joined view, delete the joined view, but NOT the saved item reference. Also note the exact name of the joined view as it appears in REST.
4. After making the necessary schema changes to the source data, you recreate the joined view with the exact name as it originally appeared in REST.
5. Your saved-as item referencing the joined view will re-path properly in the web-map and any subsequent app configurations a well. You'll need to do any reconfiguration of your layer to account for the schema change, especially if it's a new attribute field, but it won't completely break the web-app or any subsequent app. The best part, is that any pop-up, labelling, or other additional configurations of the saved-as item referencing the joined view get saved back to the reference item, so those are maintained after deleting and recreating the joined view.

The key is to be consistent and diligent in the naming conventions. Our firm uses naming conventions like this:

• Joined View Name:

[Layers/Asset Names]_Joined_View

• Use the names from both datasets partaking in the join along with “_Joined_View”

Ex:         Storm_MH_Inspections_Joined_View (where the joined layers are Storm MHs and Inspections)

Our thinking here is using “Joined_View” makes it explicit that this IS the join itself.

• Saved-As Reference Layer Name:

[Layers/Asset Names]_Join_Reference

• Use the names from both datasets partaking in the join along with “_Join_Reference”

Ex:         Storm_MH_Inspections_Join_Reference (where the joined layers are Storm MHs and Inspections)

Our thinking here is using “Join_Reference” makes it easy to understand that isn't the join itself, but the reference of it.

We didn’t like using the word “Layer” here because Layer is used so much for so many things in ArcGIS, and isn’t explicit enough.

NOTES:

• Whenever a NEW joined view is made, we should immediately do a save-as on it to create the referenced layer, then ensure subsequent configuration changes to it are saved as well.
• When you need to do a schema change to either dataset partaking in the join and require deleting the original join, you DON’T need to do another save-as to create another referenced layer.
• In the Item description of the Joined_View, enter the datasets partaking in the join and the name of the Join_Reference created from it.
• Also note that “When either of those layers require a schema change, this item must be deleted here and emptied from the recycle bin. Then recreated after the necessary schema changes are made.”
• In the Item description of the Join_Reference, enter the name of the Joined_View it was created from.
• Also note “DON’T DELETE THIS ITEM!”

I'm curious to know if others on this thread have used similar workarounds to deal with this massive limitation.