Prevent the Default version from being directly edited, only allow Post operations to update the Protected Default version

[DrewDowling]

Currently, editors with an Admin user role or Version Admin role in Portal can edit the Default version directly in ArcGIS Pro even when it is Protected.

I, and many users I have worked with over the years, find it too easy to accidentally start editing Default instead of first switching to a version. This is potentially very dangerous since there is no Undo editing Default using branch versioning.

Adding the ability to lock the Default version from direct edits would prevent this. Only Rec and Post operations will be allowed to update the default version. This would help enforce data integrity workflows and tools, such as the use of the Version difference tool.

[BrittanyBurson]

+1 - are there any other strategies for achieving this?

[RyanBohan]

As we transition to branch versioning, our preferred approach is for teams to create and manage their own versions, then perform reconcile and post operations to the default version. Since teams are most familiar with their own data, they are best positioned to resolve any conflicts that may arise.

• To perform reconcile and post operations, one or two team members need to be assigned the Version Management (VM) role. Ideally, two users per team will hold this role to ensure coverage during absences.
• However, this setup introduces a potential loophole: users with the VM role can directly edit the default version. This could prompt more team members to request VM access in order to “work faster,” effectively bypassing the intended versioning workflow.

As a safeguard, we’re considering restricting who can create versions and perform reconcile and post operations. While this would help maintain the integrity of the default version, it could also slow down workflows and place added responsibility on a small group of trusted users. These users may not be subject matter experts in the data they’re managing, which could lead to additional back-and-forth with the teams that originally created the data.

We’d appreciate any insights or experiences from others who have implemented similar workflows. How are you balancing control and flexibility in a multi-team environment?