Swap source on hosted feature layer view not updating correctly

[MappyIan]

I recently came across a blog post by @RichNauman and @EmilyMeriam1 where they describe the process of using the Swap Source function on Hosted Feature Layer Views to manage updates to Living Atlas data.  This process sounds ideal as it allows us to update data offline and only publish the changes once we've carried out the necessary verification steps.

For one of our projects this seemed the ideal way to manage updates, but we've hit a problem and hunting on this community forum it seems that we're not the only ones to have encountered this issue.  This post and this post are very similar to the issue we've been experiencing.

Our setup is that we have a public-facing hosted feature layer View of point features (cafes).  At the moment this View is connected to hosted feature layer A.  I created a copy of the hosted feature layer, made some updates and published it as hosted feature layer B.  I then used the Swap Source function to connect the public-facing View to layer B.  This worked fine and the updated data is visible in the public facing web map. 

However there are a few problems:

• on the details page for the View it says that it is still connected to layer A, which is incorrect;
• on the details page for layer A and layer B, they both list the View in the 'Other Views' section, but this should only be the case for layer B (layer A no longer has any 'other views');
• I can't delete layer A because it wrongly thinks it is connected to the View (the error message says 'These items have other items dependent on them. They must be deleted together.');
• I can't swap the source back to layer A because it thinks it is already connected to layer A so layer A isn't displayed in the list of available layers, aaaaargh;
• the final problem is that it makes it very hard to keep track of what the source of the View actually is, so from a data management perspective this could quickly become very annoying.

I don't hold out much hope given that the other two forum posts linked above have had no replies in the years since they were posted, but does anyone know why this is happening and how to get around it?  Is there any way to force refresh the AGOL interface so that it displays the correct information?  I really don't want to have to re-publish all my layers and rebuild all the various outputs.  Given the Living Atlas team use the Swap Source function it seems odd that it's not reliable.  I don't see how I could have done anything wrong as I'm using a single point dataset of just 18 features.

Any help would be greatly appreciated.

[Tiff]

I am following this as this is very clearly written out and I thank you for it! I went through this exactly similar issue around a year or so ago and it required me to fully publish a new layer and recreate all the views, unfortunately. edit - LOL the second forum you linked is mine! 

[MappyIan]

Hey @Tiff, thanks for responding.  I read your original post and wondered if you'd managed to find a way around the problem.  I'd hoped it wasn't going to be necessary to republish the layer and rebuild all the Views but I'm thinking that's going to be the only way.  Just out of interest, did you ever encounter the same problems after republishing and rebuilding the Views?  Or did the Swap Source function work fine on the republished layer?  I'm wondering if it's a consistent issue or if it's likely to be a one-off.

[Tiff]

@MappyIan No unfortunately, because as your experience describes it basically locked us into both sources without any way out! I never encountered the same problems, but the reason is because I have completely avoided swapping sources altogether. Typically what I will do, if I need to republish the layer as a brand new layer, is recreate all views (the more there is the more work of course), identify which maps had the old layer, and use ArcGIS Assistant to swap them out. Then I delete all the original layers/views.

Edit: at the time of posting I was hoping that with some time the issue would be resolved, but with how recently you've run into this issue it may still be unaddressed.

[MappyIan]

Thanks for the info @Tiff.  When I get a bit of time I'm going to do some tests to see if I can consistently recreate the issue outlined above with the Swap Source function not working correctly.  If I can replicate it I'll report it to ESRI UK Support to see if it can be fixed.  My feeling is, given how few posts there are about this problem on here (and that the Living Atlas Team seem to use the Swap Source functionality regularly), that it's going to be an intermittent problem that will be hard to replicate consistently.  In which case I don't see it being fixed any time soon. ☹️

I'll post any updates on here.

[StevenJett1]

I just recently had this issue and figured out what my problem was: I needed to make sure the new hosted feature layer has the same layer ID as the original. I am publishing the hosted feature layers from ArcGIS Pro, and you have the ability to set the layer ID in the Properties of the layer. My original was layer ID 4 and my replacement was layer ID 1, which corrupted the feature layer views after I did the Swap Source--it showed them still being associated with the original layer and not with the new one.

My solution was to overwrite the new hosted feature layer after setting the layer ID in Pro to 4. Then I was able to successfully Swap Source and it fixed the issue.

[MappyIan]

Hi @StevenJett1, thanks for taking the time to reply.  I'm aware that the Layer IDs need to match for the swap source function to work correctly.  This isn't the cause of the problem outlined above as I made sure the Layer IDs were the same prior to using the swap source function, but I'm glad it solved the problem for you.  The issue I encountered was the swap source function appeared to work correctly, but afterwards both the original and new hosted feature layers both reported they were connected to the View after the swap (but only the new hosted feature layer should have been connected to the View).

[JDenham]

*Edit -  I should point out that although I'm running into this exact same issue, I'm using Enterprise 11.3, not AGOL.*

I've just run into this same problem and would love to see it resolved. 

I only recently stumbled onto that ESRI article outlining the process, and honestly this "Swap Source" option is still incredibly helpful.  If polished / supported by ESRI, it will be a significant help in managing the web layers that we use in our web applications.  

As a temporary workaround, I'm now maintaining 3 separate web layer versions.  Because I assume that I'm also unable to delete the originally paired web layer, I've created two additional published layers that I plan to toggle between for updates, leaving the originally paired layer alone.  Feature Layer Unique ID's are always aligned because I'm publishing these additional web layers in ArcGIS Pro from the same Project and GDB as the original web layers, with identical layer ID's.

*This does not solve the awkward issue of keeping track of which layer is the actively reference one, and which one is safe to over-write with future updates.

There is still an advantage for me to use this 'swap source' method though.  I know the guidelines in the article are clear that the schema must match, but I've found that this works as a method of making simple data schema changes and getting them to properly translate through the View layer into the web maps/web apps in a way that doesn't happen properly if I overwrite the web layer directly.

I'm working with indoors maps, so my web layers only include the 4 indoors feature layers (Facilities, Details, Units, Levels) with "Units" being the only one ever needing schema changes.  For example, I'll set up the initial schema to meet the customer's request, configure a web map, and pull it into a web application for the customer to start working with.  Our customers edit and reference their data directly into the hosted layer via the web application, and my involvement takes a backseat unless they need me.  As their needs expand or change, they'll come back with additional fields and/or domain lists for various fields that are needed.  Before I discovered this 'Swap Source' option, I kept running into issues with the Layer View not detecting changes I had made to the data.  I could see the changes in the hosted web layer, but they would not translate into the Layer View (additional fields would simply not show up at all in the "Update View" process) and therefore would fail to be seen by the referencing web map/web apps.  

When I instead publish a new layer and swap the view source to it, these schema changes are detected by the View and translate into the referenced maps/apps.  Aside from the other problems described above, this still solves a significant problem for me.  If this can be corrected so that the source metadata was properly updated with each source swap, I could simply toggle between two web layers, and more importantly, I'd be able to quickly verify which source was currently being used by the view.

-Jeremy

[MappyIan]

Hey there @JDenham, thanks for taking the time to comment on this post.  I've got a couple of comments about two of thing points you raise in message.

"...If polished / supported by ESRI, it will be a significant help in managing the web layers that we use in our web applications."

I totally agree that if the 'swap source' functionality reliably worked as advertised 100% of the time it would be a game-changer for managing some of our projects.  But we've found in practice that it's just not reliable all the time.  Most of the times it works fine, but occasionally it just doesn't work and totally messes up the data causing hours of work to resolve.  Consequently we just don't trust the function to work so have set up reliable alternative workflows.  The thing that annoys me most about this is that this is documented functionality that is fully supported by Esri so should work.  Every.  Single.  Time.

"...I kept running into issues with the Layer View not detecting changes I had made to the data.  I could see the changes in the hosted web layer, but they would not translate into the Layer View (additional fields would simply not show up at all in the "Update View" process)..."

I spotted this same problem a while ago (March 2022) and logged it as a bug with Esri Support.  I just went back to see what the status of the bug is and it's still 'in review': https://support.esri.com/en-us/bug/unable-to-add-new-fields-to-the-hosted-feature-layer-vi-bug-00014..., which is disappointing.  When I initially logged this bug we found that you could edit a View once, but any subsequent changes to the underlying hosted feature layer weren't visible in the 'Update View' area.  However, since logging this bug we've found that it's not quite as clear cut as that and that some Views can be updated multiple times.  It's annoyingly inconsistent but I live in hope that one day Esri will fix the issue.  Again, updating Views is documented functionality so it should work, but the unreliability means we can't rely on it always working so have to put in places processes that we know will work even if they take longer.

[JDenham]

I agree with you that this needs to be a reliable workflow in order for it to be truly useful.  It's disheartening to hear that you have had inconsistent results and time loss.  Can you share how the source swapping failure occurred for you?  Did the process simply corrupt your View Layer, forcing you to start with a fresh View Layer and reconfigure everything downstream?  

I just got off of a support call discussing the original issue of the metadata not updating with the source swapping, and he shared this bug report with me.  It is listed as resolved in Enterprise v.11.5 (which at this time isn't yet released).  I don't know if this fix applies to users on AGOL as well, but I would hope so.  Being that features / fixes typically deploy in AGOL well before they are seen in Enterprise, I wonder if this has already been implemented for you.  *I'm assuming that you are working in AGOL since that is the corner of ESRI Community that we are in.*

During our support call, I shared your report of unreliable source swapping, and he suggested retesting reliability of the process again after the above bug fix is in, because they may be connected.  If you work in AGOL and have the time to test if the metadata swapping is now functional, it might be worth revisiting this workflow to see if it the other issue has been resolved as well.

-Jeremy