Disappearing Edits in a Crew-Synced Utility Geodatabase
An electric cooperative with 1.2 million distribution assets runs ArcGIS Enterprise on a single relational geodatabase. Thirty-eight line crews edit poles and conductors from trucks through a sync-enabled feature service, often for six to eight hours with no signal. A nightly Python script reconciles and posts every crew version into the default version, then rebuilds a read-only replica that feeds the outage management system. Editors report that their changes disappear and later reappear, roughly 400 reconciliation conflicts arrive each week, and a pole relocation completed by Crew 12 on Tuesday was overwritten by a stale edit from Crew 27 on Wednesday. The outage system occasionally reports pole locations up to 300 m from where crews say they are. Storage is at 78 percent, and the nightly job now runs 5.5 hours, sometimes overlapping the 06:00 outage-system refresh.
1. Identify the likely causes of the disappearing edits and the Wednesday overwrite, and evaluate whether the nightly post-and-reconcile design is the right fix.
Read the worked answer
Six to eight hours offline means each crew's local copy diverges substantially from the default before it ever syncs. Under traditional versioning, the nightly reconcile compares each crew version against a default that has already moved, and the post policy decides who wins. A default of 'in favor of the edit being posted' is exactly how a Wednesday sync from a stale local copy overwrites Tuesday's field observation. The disappearing-then-reappearing edits are consistent with a mid-session replica refresh or a version change that pulls back a state the crew has not finished editing.
The nightly post is not the fix; it is the mechanism producing the symptom. Two credible paths:
- Shrink the divergence window with mandatory sync at yard checkpoints, at shift end, and before any edit to a critical asset, plus an explicit per-class conflict policy.
- Migrate to branch versioning through a sync-enabled feature service, where conflicts are detected at save time and resolved per feature by the editor, removing the nightly post bottleneck.
Branch versioning is a one-way migration and changes the editing workflow. Pilot it on one district and confirm behavior against your specific release before committing.
2. Design the conflict-resolution policy and QA controls, including how to handle the 300 m location mismatch and the growing nightly job.
Read the worked answer
Write the policy before you need it, at feature-class granularity. A field observation made on site should generally beat an office edit derived from paper, but a survey record or as-built should beat both. The decision must key on observation date, not sync time, because sync time is an accident of connectivity.
Never let automated post silently take a side on geometry edits. Route conflicts to a queue with a named steward and a 24-hour turnaround, and report conflict counts by crew and by class weekly so a single bad workflow surfaces early. Require attachments (photo, GPS observation) on edits to poles, switches, and anything feeding the outage model. Populate verified-by, method, and observed-date fields, and exclude unverified edits from the outage replica until they pass review.
For the 300 m mismatch, treat it as a data-quality finding: pull both versions, compare against the crew's GPS and the as-built, correct the record, and push the correction through the replica. For the 5.5 hour job and 78 percent storage, the diagnosis drives the design. If the run time comes from reconciling 38 long-lived versions, shortening the divergence window reduces it directly. If it comes from replica rebuild, move to incremental replica sync and archive retired versions rather than accumulating them.