Gas Utility Version Conflicts and Dirty Areas After Posting
A gas utility has 62 editors working in ArcGIS Pro against a branch-versioned utility network service. The default version is used for publishing, and each of four districts has one named version. Editors in the same district all edit the district version. Field crews close valves and update status; office editors add new services. During a morning shift, an editor saves a valve status change and receives 'The version has been changed since you started editing.' Another editor cannot see valve closures made 20 minutes earlier. At the end of the day, a supervisor posts the district version to default. The post succeeds, but the utility network has 280 dirty areas and several traces return incomplete results. The utility wants to keep one version per district for simplicity but reduce conflicts.
1. Diagnose the versioning and visibility symptoms. Would you keep one version per district? Justify your recommendation.
Read the worked answer
The conflict message is a branch-versioning concurrency symptom: multiple editors are saving to the same version, and one editor's save invalidates another editor's open edit session. The invisible closures are expected because branch versions isolate edits; another editor will not see them until the version is saved, refreshed, reconciled, and posted, or until both editors are in the same version and refresh their map. One version per district with roughly 15 editors per district concentrates contention and makes the conflict message likely. I would not keep a single editable district version for all editors. Keep the district version as an integration parent, but create child versions per crew or per editor and reconcile them into the district version on a schedule. That preserves the district-level simplicity the utility wants while reducing concurrent saves. Require editors to save and stop editing before the supervisor posts, and refresh the map after reconciliation.
2. After the supervisor posts, 280 dirty areas remain and traces are incomplete. What post-processing sequence do you require before editors resume?
Read the worked answer
Posting a version does not automatically validate the network topology. The dirty areas indicate features whose topology has not been validated after the edits. The required sequence is: validate network topology for the posted extent; inspect and resolve error features; update the affected subnetworks, especially where valves or services changed; then run representative traces and confirm they return expected results. Also check that all subnetwork controllers are still valid and that no dirty areas remain around the edited valves. Only after validation errors are cleared and sample traces are correct should editors resume. If validation produces errors that cannot be fixed quickly, keep the affected district in its named version, fix the data, and post again rather than letting editors work on an invalid default version.
3. What version ownership and permission rules would you set to prevent a supervisor from posting while others are still editing?
Read the worked answer
Make version ownership explicit. Editors should own child versions; supervisors should own the district integration versions and the default version should be treated as the published integration version. Grant edit permission on child versions to the crews that need them, and keep post permission limited to version owners or administrators. Before posting, require the supervisor to use version manager to inspect child versions, confirm they are saved and reconciled, and confirm no editors are connected. Use a scheduled cutoff: editors save and stop editing at a set time, the supervisor reconciles and posts, then validates topology before reopening editing. If ad hoc posting is necessary, require a short lock or communication step. These rules prevent posting a version that still has open edit sessions and make the integration step predictable.