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

[PhilipOhlinger]

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.

[Calvin_Wong]

I would also like to see this. It's frustrating having to delete the joined view and re-create it. The view is usually linked to dashboards or Experience Builder and this breaks since the item ID changes after a re-creation.

[DamienDiVittorio]

As a new user on AGOL this issue was extremely frustrating to me!  It took me quite a while to figure out why I couldn't edit my hosted feature layers.  There has to be a way to lock only the fields used to define the joined view and allow schema and domain changes elsewhere. 

At a minimum, their could at least be a pop up to warn users that creating joined hosted feature layer views will not allow schema changes on the parent features/tables.  This has been a known issue for years.  ☹️

[Kaz]

Agree, this limitation needs to be VERY obvious when you create a join layer, and there needs to be a way to update the source schema afterwards. 

Example: A survey is created. The survey feature layer then participates in a live join view. Then you are unable to make changes to the survey. 😞 

[WillyG]

We just need a button to disconnect the joined view layer from the source, make schema changes and then reconnect in a seamless manner that would not cause disruption to the end user. Perhaps this could be handled with the update view workflow, not dissimilar form what we have with regular views. How about the ability to swap the source of the hosted join layer to a temporary slave 'Layer'. We can then make changes to the master while we are in this limbo stage and the end user wouldn't notice anything.  This seems like it should be reasonably straight forward to implement. Currently we are bending over backwards to provide complex workarounds for this 

[MattyMaps]

A pause and refresh view option would solve this

[DevinCarlson]

A solution to this workflow is definitely needed!  

Or - a better recommended practice to be able to symbolize features based on the most recent inspection that lives in a related table.

Specific use case:  Hydrant Flushing
Hydrant feature is related to Hydrant Maintenance Inspection table.
Currently, we are utilizing the joined view layer to show our field crews and department heads when a recent flushing event occurred - in Field Maps and Experience Builder.  When changes to the schema are needed or domains need to be updated/changed - which is inevitable - the join view layer needs to be deleted, changes made, then recreated, resymbolized, and added back into any maps or applications.  Very tedious workflow.

We have also tried to use an Arcade Expression in the parent hydrant feature that looks at the related table and populates the parent feature with information from the inspection.  This could work, but I am unable to get the parent table to update automatically when the inspection record is submitted.  We have to start to edit the parent feature, then the data populates (working in Field Maps).

Regardless, a better workflow to utilize inspection data that lives in a related table is very much needed!

[jfisher]

One possible work around mentioned here is to programmatically find and replace item id's in the definitions of all affected items using the arcgis python api. Using this solution means you need to keep careful track of any item that references your joined-hosted layers.

We have not stared using joined hosted feature layers yet. They are potentially powerful, but this limitation is preventing me from really embracing them.

[WillyG]

I was hoping with the new recycle bin functionality that after we delete the joined view layer it would then unlock the schema, and then we could make our changes to the schema and then restore the joined view layer, but the schema of the master is still locked while in the recycle bin unfortunately. There must be a simple solution to this. We just need a workflow to to swap the joined view layer or disconnect it temporarily so we can unlock schema. We have an update views option in the settings for regular views. Why not joined view layers? 

[JeffShaw]

Needing to delete joined views in order modify the joined layers makes them not worth the significant effort and risk to configured apps in almost all cases. 

We NEED Esri to get serious about finally providing useful relational data structures in ArcGIS Online after all these years. As a user of Esri products for 37 years I can say that the lack of support for this is baffling and has significantly curtailed the effectiveness and efficiency of our agency in managing natural resources.

[WillyG]

Couldn't agree more @JeffShaw  When hosted view layers were re-released in June 2023 it was stated in this blog: that the ability to allow schema changes in source layers is coming Join us in welcoming joined views to the item details page (esri.com)... It has been over a year and there has been complete radio silence.  Even giving us functionality to disconnect / reconnect using something like AGOL assistant or view swapping like what is in the regular hosted view workflow is better than nothing.