Proposed Data Service Publishing and Configuration Strategy

Question

Good day, I would appreciate any feedback on the proposed Data Service Publishing and Configuration Strategy, particularly from those with experience managing ArcGIS Enterprise environments.

Specifically, I would be interested in understanding:

* Whether this approach has introduced any performance impacts in your environment.
* Any operational or administrative challenges associated with managing a large number of Portal Layers (Views).
* Potential limitations or considerations when using Portal Layers/Views as the primary mechanism for managing symbology, pop-ups, labels, and other presentation settings.
* Any best practices you have adopted to ensure scalability and maintainability within ArcGIS Enterprise.

My objective is to establish a configuration model that promotes reusability, consistency, and simplified maintenance while avoiding unforeseen performance or management overheads.

I would welcome any insights, lessons learned, or recommendations based on your experience.

Kind regards,

Jorn Sijbertsma

Proposed Data Service Publishing and Configuration Strategy

To improve maintainability, consistency, and governance across our GIS environment, I recommend the following approach:

* Maintain a single authoritative source service (Map/Feature Service) for each dataset, published from ArcGIS Pro without symbology, labels, pop-ups, or other presentation-specific configurations.
* Create Portal Layers (Views) from these source services and manage all presentation settings (symbology, labels, pop-ups, visibility scales, etc.) within the views.
* This allows changes to be made once at the layer/view level and automatically reflected across all consuming web maps and applications.
* Avoid configuring layers directly within web maps wherever possible, as this creates duplicated configuration and increases maintenance effort.
* The current corporate viewers implementation demonstrates this challenge, where the same layer settings are replicated across multiple web maps, requiring each map to be updated individually whenever a change is needed.

Overall, managing configuration through Portal Layers/Views provides a more scalable, consistent, and sustainable approach, while significantly reducing ongoing maintenance and change-management effort.

JonM32 · Answer

@D_Atkins

The only thing that comes to mind is an issue I've had with republishing/overwriting services from ArcGIS Pro to change popups. Basically, only the original publisher of the service can overwrite/change the popup and not a different user. For example, say employee 1 makes a service, publishes it with a bunch of custom popup stuff in ArcGIS Pro. Then a few months layer, there's an idea to make a change in a popup. Employee 2 goes into Pro, makes the change to the popup, and tries to overwrite the service. I've tried this in the past and nothing happens in terms of popups being changed. I found that only the original person who published it can make that update to the popup through the overwrite workflow. I'm assuming this is still true, it was about 6 months ago when I tested it.

Here is a post that refers to this issue from last year: Solved: Pop-ups not updating when overwriting services on ... - Esri Community

D_Atkins · Answer

We've been considering some of the same challenges; if anyone notices anything I've written is wrong, please chime in!

From what we've gathered, best practice is to maintain the highest standard or highest priority configuration (symbology and popups) in an ArcPro map.  This way, republishing the base service and MapImageLayer is straightforward and schema changes (i.e., new fields, or new domain values) are immediately available in the 'priority' application.  (The MapImageLayer is already there anyway, why not clean it up and take advantage of it?)

Secondary products (maps, apps) built off of these services with customizations performed in MapViewer or similar end-user applications will not be updated when a service is republished.  Getting something like a new field or new domain to these applications requires opening the map, reloading or resetting the layer, and then redoing any customizations.

Some background on how I arrived at these thoughts, specifically with two comments I've yet to fully digest:

from @NicoleJohnson, (permalink)

@AdrianMarsden, maybe I'm misunderstanding, but you can control the pop-ups only as long as you do not customize them in Map Viewer. That's what the quoted part from Overwrite Web Layer means. I.e., if you've customized them in Map Viewer, it's safe to assume you wanted the pop-ups to be that way in that map?

...format the pop-ups before publishing (and do not change them in Map Viewer) if you want those changes to propagate to everywhere you're using the layer straight from the source without customizations. Another method would be to change whatever (symbology, pop-ups) at the item level (go to the Visualization tab on the item page) and save. You can also just reset back to the source layer properties from the Properties tab in Map Viewer

and from @RobertKrisher, (permalink)

the best practice is to put the majority of your definitions for symbology, labels, etc in a web map instead of the service. The feature service definition doesn't support the full capabilities of the web map, so you'll always need a web map to create full-features web/mobile applications. Additionally, putting all your configuration in a feature service means you're limiting yourself to only supporting a single user experience. A single feature service supporting multiple web maps uses less server resources and is more scalable than creating a bespoke feature service for each web map.

I generally agree with Robert, that most Orgs will want to use one service in multiple apps (reiterating the need for some management in the Portal MapViewer, even with a highly curated Pro Project).  Note that I somewhat disagree with the bold statement, especially the word 'always'.  We use the Javascript SDK to create 'full-featured applications' quite regularly without the overhead of a WebMap in Portal (while still leveraging Portal Item ContentIds and the sharing controls therein).

JonM32 · Answer

@JornSijbertsma

Interesting approach to service management. I like the idea of this and think it could work well.

One thing I would suggest testing is after you make a service and configure a view layer, add that to a map and see if a user can change the symbology/labeling/etc of the layer. Then save the map and go back and try to reconfigure your view layer. If your plan is to update symbology of a view layer in all maps it's used it, but the user is able to change what it looks like and the map lets them save, it may prevent your workflow from working. That's what happens to our services once someone changes just one aspect of them and saves a map...the map saves their settings and essentially disconnects it from our overwrite workflow to update services. We don't use view layers much where I work so I don't know the answer to this, but something to look at.