When you add a layer to a service, the webmap does not see it. Until you re-add the layer. We have to redo all popups, labels, symbology, other webmap settings etc. Stressful for production viewers.
First, ideally the issue of webmap staying in sync with services will be resolved in an AGOL update.
So re-adding it will become unnecessary. (in other words we shouldn't need to constantly re-add a service to a webmap just because we add or remove layers in the MXD)
But the connected issue to this, is it changes the 'id' of the service 'layer' in the webmap JSON, if you re-add a service. This needs to remain static or at least have some way of us being able to arbitrarily set it, so I can change it back to what it was. Or perhaps (and in addition to, as an optional alternative) reference the layer by 'name' as I proposed last year.
The reason the 'id' is so, so important is it is vital to how the Share widget in webApp Builder works, and how we can programmatically do things like expand layers in the layer list or do other actions. Because this 'id' gets carried into the DOM node IDs.
From my earlier thread....
The Share widget in the WebApp Builder is an amazing, amazing feature. Truly an amazing functionality. For example this URL zooms to an address https://www.sagis.org/map/?query=SAGIS2018allLayers_9233_124%2CPROP_ADDRESS%2C10%20WESTGATE%20BLVD%2... Or I could do it by PIN or Name etc etc. But... if I add a layer to my viewer service, which is inevitable... it will change the "id" (9233) of the layer/service in the webmap.
This prevents integration of Esri viewers with other systems. Because let's say another agency wants to tie into my viewer. If the ID didn't change, it'd be easy, just give them the URL and tell them to append the PIN or Address or whatever, to the end of the URL. Presto, it zooms the map to a feature based on a query. But.... the second I re-add the service, this will break because the ID 9233 changes to another number. Now all they would have to do is update their URL. But... asking a government agency to repeatedly change something is definitely not feasible. It just won't get implemented unfortunately, no matter how quick the change, it requires a change which means not feasible.
I suggest this ID remain static and unique not change. Even if we re-add the service, it should know it is the same service and have the same ID or even allow us to update the ID. I'm sure I could change this in the JSON but I don't want to change something so drastic in webmap raw JSON unless I know it won't have any other ramifications. The Share widget allows for amazing integration of Esri viewers with other systems - however, this is a roadblock until we can get the ID to remain static.
Somewhat secondarily, it affects customizing the layer list because the ID gets baked into the DOM as I noted above. Not too bad for me to just update the DOM ID references. But asking other agencies to update production systems like the tax assessor each time I add a layer will not be feasible.
.....
I understand updating a vast platform like AGOL will be a long-term process and we want to get it right, for a new milestone update. However, I would recommend this ability to have services stay in sync with the webmap be a feature that is added to the next-gen AGOL.
https://community.esri.com/ideas/15068-webmaps-that-actually-work
https://community.esri.com/ideas/15734-option-to-use-layer-name-instead-of-layer-id-number-for-servi...
https://community.esri.com/ideas/15372-enh-000108149-enhancement-allow-the-option-to-refresh-or-rese...
