This change has a very narrow scope and will not affect the vast majority of ArcGIS Online users. If you publish and manage your data through the ArcGIS Online website using tools like Map Viewer or content pages, this change does not impact your workflows. Existing services, hosted feature layers, views, maps, and other content will continue functioning exactly as they do today.
It is important to clarify what this change does not affect. First, this change applies only to ArcGIS Online and does not impact ArcGIS Enterprise environments. Organizations using ArcGIS Server, Portal for ArcGIS, registered data stores, enterprise geodatabases, or server-published services are unaffected. Additionally, Hosted Feature Layers — the most commonly used layer type in ArcGIS Online — are explicitly excluded from this change. Users can continue creating views, tile layers, OGC layers, and other derived content from hosted feature layers without modification to existing workflows.
This update also does not impact publishing workflows performed through the ArcGIS Online user interface. The ArcGIS Online website has already enforced a one-to-one relationship between source items and published services for years, meaning users who publish exclusively through the browser experience will see no change. Existing content is also unaffected, as this update is not retroactive and will not break, remove, or modify previously published services.
What this change does introduce is enforcement of an existing publishing rule within the ArcGIS Online REST API, specifically within the /publish endpoint. In practical terms, organizations that use custom scripts or applications that directly interact with the REST API to publish multiple services from the same uploaded source item will now receive an error when attempting to do so. Previously, these workflows may have succeeded despite differing from the behavior already enforced within the ArcGIS Online user experience.
This change affects source item types that are commonly uploaded and published through automated workflows, including CSV files, Shapefiles, Microsoft Excel files, Service Definitions, Tile Packages, Compact Tile Packages, Feature Services, File Geodatabases, SQLite Geodatabases, Feature Collections, Image Collections, GeoJSON files, GeoPackages, Vector Tile Packages, Scene Packages, Map Services, 3D Tiles Packages, Analysis Models, and Deep Learning Packages.
Organizations are only affected if all three of the following conditions apply: they use custom scripts or direct REST API publishing workflows rather than the ArcGIS Online interface, those scripts publish multiple services from the same uploaded source item (same item ID), and the source item being published is not a Hosted Feature Layer. Organizations uncertain whether they use workflows like this should consult the teams or individuals responsible for ArcGIS Online automation and publishing processes. If no custom publishing automation exists, this change likely does not apply.
For organizations that are affected, the required adjustment is straightforward. Instead of publishing multiple services from a single uploaded source item, each service should have its own dedicated source item. For example, rather than uploading one Shapefile and publishing multiple services from it, organizations should upload separate copies of the Shapefile and publish one service from each uploaded copy.
As part of updating automation workflows, scripts should be modified to upload or duplicate source data so that each service has a dedicated source item and then publish services independently from those unique items. Following the June 24, 2026 release, attempts to publish a second service from a source item that has already been used for publishing will return a'PUB_0067' error.
This update is being introduced to align backend publishing behavior with rules already enforced throughout the ArcGIS Online user experience. Enforcing a one-to-one relationship between source items and published services simplifies item relationships, reduces publishing inconsistencies, and improves long-term maintainability of content management workflows. This approach follows similar standardization efforts introduced in previous releases related to item type restrictions.
