Esri has long relied on the access‑level model of private – protected – public. This approach worked adequately in traditional versioning environments, where editing was performed primarily through desktop workflows.
With the shift of editing capabilities to the web, however, the requirements for controlling access to the underlying database have become significantly more complex. This is especially true for Utility Network, where editing is performed through services rather than direct database connections.
Because editors now access services using their Portal identities, version access should be governed by groups, not by database‑level access settings.
One of our key use cases involves external contractors editing our services. These users should only be able to view versions created by themselves and their colleagues from the same company. The existing “public” access level cannot support this requirement, whereas group‑based version access can. Private restrictions are thus not feasible, as it would not allow access for their colleagues. This issue can be resolved by group based version access.
We have also encountered an issue where a Creator with a custom role that includes the Version Management privilege so that they can post changes from a public version to sde.default (which is protected). In this scenario, the user is able to edit features in sde.default directly because their maximum privileges override the intended restrictions (see ENH‑000181241).
In short, Esri has to think beyond the private - protected - public access permissions and adapt to a more user group based approach of access levels.
