ArcGIS Utility Network in Action: Day-to-Day Workflows After Go-Live

A Utility Network migration shouldn’t feel like a leap into the unknown. With the right preparation and training, teams can understand what everyday editing will look like long before the system goes live. This post offers a clear, approachable preview of the workflows and concepts that shape daily life in the ArcGIS Utility Network; because when people know what to expect, adoption is smoother and the system delivers value faster.

A Modern Approach to Editing

Branch versioning is one of the biggest shifts organizations encounter with the Utility Network. Branch versioning is Esri's service-based, multi-user editing model built specifically for systems like the Utility Network and Parcel Fabric.

Branch versioning uses a temporal, insert-only model, meaning every edit (even deleting a feature) creates a new record in the database. Rather than overwriting or updating rows, the system tracks edits to each feature over time, natively allowing it to maintain historical records for each feature.

Because branch versioning operates through feature services rather than direct database connections, as in 'traditional' versioning workflows, management tasks for alpha and delta tables and routing database compression tasks are no longer required.

Named Versions

Editing in the Utility Network takes place in named versions, which serve as workspaces for editors. Edits are made in these named versions, validated, and then posted to the authoritative parent ("Default") version.

A few technical details on named branch versions:

• Versions are created and managed by the Version Management service, which is part of the ArcGIS Enterprise/Portal feature service, not in the database.

• Versions include access levels of Private, Protected, and Public, to control visibility and edit rights for users.

• Reconciling brings Default's updates into your named version; posting pushes your completed work into the Default version.

Concepts that help teams understand why editing within named versions matters:

• Editors can safely save, discard, and QA their work within a named version.

• Errors are caught before anything reaches Default.

• Default remains the trusted authoritative data source.

• Multiple editors can work in parallel.

Smart Feedback That Improves Data Quality

Utility Network editing introduces "Dirty Areas", namely purple areas for unvalidated edits and red areas for rule violations. This functionality provides users with real-time feedback. When you validate topology, the system checks your edits against the Utility Network configurations, such as:

• Connectivity rules (is this device allowed to connect to that line?)

• Association rules

• Containment relationships

• Terminal configurations (inlet/outlet, phase, pressure direction)

• Subnetwork configurations

To fully understand what the system is telling you through dirty areas, it helps to distinguish between the five specific types of dirty areas.

1. Disabled indicates the network topology has been turned off, usually for bulk loading or schema updates.

2. Dirty is the standard state for new, unvalidated edits. These are the purple, hatched, dirty areas that appear as features are edited and created, but before they have been validated.

3. Error confirms a violation of rules and restrictions during validation.

4. Dirty and Error indicates an existing error feature has been modified but not yet re-validated.

5. Subnetwork Error points to larger logical issues, such as invalid features or disjointed subnetworks, rather than just a local connectivity geometry issue.

This immediate feedback loop is a big advantage of the Utility Network. Instead of discovering data problems long after edits have been made, editors get clear, guided corrections in the moment.

Subnetworks

Most utilities organize their assets within logical zones, such as pressure systems and circuits. In the Utility Network, these become subnetworks, and their accuracy determines how reliable certain tracing and analysis will be. Once subnetworks have been created, the Update Subnetwork tool refreshes cached subnetwork information so that the topology reflects the latest edits.

Some organizations automate this process and run Update Subnetwork on a recurring schedule. Others make it part of daily or weekly editing workflows. Either approach works, as long as subnetworks stay up to date, because stale subnetworks lead to an inaccurate representation of the system.

Tracing for Everyone

Tracing is a powerful component of the Utility Network. Complex analyses, such as valve isolation, outage impact, or downstream flow, can be packaged into name trace configurations.

A named trace configuration stores:

• The trace type (upstream, downstream, isolation, etc.)

• Barriers and conditions

• Filters (pressure zone, phase, diameter, status, etc.)

• Output settings and result formatting

Once published, these configurations can be used in simple web applications. This allows field staff, supervisors, and customer service reps to run powerful traces with just a few clicks.

Imagine:

• A field supervisor instantly sees which valves isolate a break.

• A customer service representative identifies all affected customers.

• A dispatcher running outage impact analysis without calling GIS.

Tracing becomes an everyday tool across the organization, not just for people with GIS in their job description.

Preparing Your Team for Success

The Utility Network isn't just new software; it's a new way to manage and understand your system. Exposing your team to key concepts early helps in making the go-live process feel like a natural transition rather than a disruptive shift.

When teams understand the "why" behind these concepts, embracing the "how" becomes much easier. With proper training and communication, go-live isn't a disruptive shift; it is the next step toward a more accurate, accessible, and responsive GIS environment.

Contact our team for help preparing for or migrating to the ArcGIS Utility Network!