Strategy to integrate ArcGIS Utility Network

This decision guide provides an architecture decision framework for integrating enterprise systems with ArcGIS Utility Network.

Utility Network integrations should use supported, service-based access patterns that maintain authoritative network information, respect versioning and workflow processes, and align integration methods with the required level of data, connectivity, and operational responsiveness.

Architecture decision

This design guide helps answer the question of how to approach integration of the Utility Network with other business systems. Multiple integration patterns can be implemented as part of a complete solution, so each integration requirement should be evaluated against consistent criteria, including the customer’s information, workflow, data currency, workload, security, and supportability requirements.

Each option has benefits, limitations, and operational implications. The selected pattern should balance information requirements, versioning and workflow needs, data currency, workload characteristics, security, and supportability.

Decision stakeholders

The decision should be agreed upon by the solution or platform architect, the administrators or owners of the integrated business system, and the IT teams responsible for the supporting infrastructure and integration platform. Each stakeholder brings system constraints, policies, operational requirements, and service-level expectations that must be considered.

Prerequisites

• Confirm the integration is required.

• Inventory or discover relevant policies and IT standards applicable to the systems being integrated.

• Inventory existing interfaces and integration patterns supported by both systems.

• Estimate generic interface load such as scope, frequency, duration, payload sizes, SLA, concurrency, fault tolerance, and so on.

• Establish the specific data requirements, such as what objects, lifecycle states, attributes, and properties must be interfaced.

Downstream architecture impacts

• Interface dependencies on workflows such as reconcile and post.

• Interface load on architecture components such as database or server resources.

• Information recency, workflow duration, and perceived end-user performance can also be affected by the selected integration pattern.

Consider the context

Before making a decision, consider the context for integration.

Utility Network requires ArcGIS Enterprise services

Service-based integration requires an authentication framework that allows the integrating system to securely access ArcGIS Enterprise services.

The integration identity must have the privileges and licensing required for the Utility Network operations and functionality it invokes.

Integration design must therefore align with the organization’s ArcGIS authentication and authorization patterns.

Utility Network uses branch versioning

• Branch-versioned data should be accessed through services or supported ArcGIS APIs. Direct SQL access is discouraged.

• Data in the Default version can be accessed through supported client-to-database workflows (for example, ArcGIS Pro or ArcPy) or through client-to-server service connections.

• Data in named versions is accessed through client-to-server connections, such as services and supported ArcGIS APIs.

• Data existing in versions is often planned or proposed, unless by design objects with this state are posted to the default version.

• Until a version is reconciled, object edit history is also maintained in the version branch.

• Integrations accessing user versions must be cognizant of exclusive version locks to prevent interrupting user edit sessions.

• Branch-versioned data allows access to historical changes as well as change detection through a differences API, which can be used for interfaces that require deltas. Network-managed or derived fields updated through Utility Network processes may not follow the same change-history behavior as direct feature edits; where authoritative network-managed values are required, trace or export-based workflows may also be needed.

Utility Network manages key attributes

When integrating with Utility Network data, critical fields within scope are often managed by the network, such as subnetwork name, state, status, voltage, pressure, and phase.

• The eventing setting in Utility Network configurations can disable updates to certain fields while data is in a version (for performance reasons) and update those fields only in Default.

• Certain fields are system managed or derived only when the data participates in a subnetwork and the subnetwork is updated. These fields cannot be directly written through integration.

Utility Network data often leverages deferred calculation and validation rules

• Integrations must be mindful of potential for delayed attribute updates configured to execute at specific times in an editing workflow.

• Batch attribute rules may also be configured to only update in the default version.

• Batch attribute rules may be used by integrations to delegate complex business logic to the geodatabase.

Network model access

The first decision point is whether the integration requires network connectivity. Network connectivity is obtained through Utility Network service operations such as Trace or Export Subnetwork. When connectivity is required in real time or near-real time, a service-based approach is required. When real-time access is not required, scheduled batch processing can export subnetworks or other required outputs for downstream consumption.

Subnetwork-based vs. Trace-based integration

Subnetwork-based integration accesses or exports network connectivity from preprocessed subnetworks. This pattern provides a consistent, reusable representation of the network for downstream systems. The Update Subnetwork policy and IsDirty state are important controls because they indicate whether a subnetwork reflects the latest validated network state; Last Exported information can be used to manage downstream currency.

A dirty or invalidated subnetwork can lag behind the latest feature edits until topology is validated and the subnetwork is updated. Integration design must therefore explicitly prioritize either the latest feature state or an authoritative, processed network representation. Where authoritative connectivity is required, the interface may need to wait for Update Subnetwork processing before export. Large networks may require additional operational planning to keep subnetworks sufficiently current.

Trace can evaluate connectivity on demand, including situations where dirty areas exist; however, results may not represent a fully validated network state. Use caution when trace results feed critical operational or safety-related systems. For those integrations, favor an authoritative subnetwork-based representation when consistency is the primary requirement.

Recommendation: For critical operational or engineering/analysis systems that require a consistent network representation, subnetwork-based integration is the preferred pattern.

Interface connection options

Service / REST API access is the default preferred integration path in this guide. Direct database access is treated as a narrowly scoped read-only exception and must not be used to edit branch-versioned Utility Network data.

Service/REST API access

Service/API access is the most comprehensive integration pattern in this guide. It supports feature access, named-version workflows, Utility Network operations, change detection, and network-model operations while preserving the ArcGIS Enterprise security and service boundary.

• Supports read/write operations to default and named versions

• Supports differences and change detection

• Enables export of network element connectivity model

Direct database read

This option uses native RDBMS queries, views, or procedures to read underlying branch-versioned data. Direct database integration should be treated as an exception for narrowly scoped read-only requirements. Direct SQL must not be used to edit or append to branch-versioned Utility Network data; supported editing or loading workflows use ArcGIS clients, services, or supported APIs as appropriate.

Direct SQL access to underlying tables requires knowledge of branch-versioned query logic to provide the correct view of the data and may introduce performance risk if queries are not designed appropriately.

An alternative supported approach is to read the data through an ArcGIS client library such as ArcPy. In this case, branch-version logic is handled by the client.

A benefit of this approach is that authentication is at the database level and only introduces load on the database.

Utility Network-specific functions such as trace, network element connectivity, and diagrams are not available.

Version differences and change detection would have to be customized.

Batch options

Batch trace: configurable tracing tool to execute n number of preconfigured traces.

Scripted export: custom scripting to export subnetworks or custom queries.

Reporting database: Maintain a separate repository optimized for reporting, analytics, data warehousing, or high-volume consumption. Populate it through supported ArcGIS Enterprise service, export, trace-output, or change-detection workflows on a defined schedule. This pattern isolates resource-intensive consumption from the operational GIS but introduces synchronization latency.

Recommendation: Service/REST API-based integration should be the default preferred approach. Use alternative patterns only when a specific requirement justifies the tradeoff.

Making the decision

Use the comparison matrix to understand capability and operational differences, the decision matrix to map a specific requirement to a starting pattern, and the decision framework to apply those choices with the stakeholders identified earlier. The options are not mutually exclusive; a complete integration solution may combine more than one pattern.

Comparison matrix

Decision factor	Direct database access (read-only exception)	Service / API	Differences API	Trace	Export subnetwork	Reporting database
Information requirement
Stored feature attributes	Yes	Yes	Changes only	Identifiers only	Identifiers only	Yes
Network connectivity information	No	Partial	No	Yes	Yes	Yes
Network-managed or derived attributes	Last successful update	Last successful update	Changed values only	Yes	Last successful update	Depends on source and refresh process
Delta detection	Custom compare	Custom compare	Yes	Custom compare	Custom compare	Custom compare
Version and workflow
Version access	Default	All	All	All	All	Source-dependent
Current subnetwork-derived values	No assurance	No assurance	No assurance	Not applicable to stored values	Update Subnetwork may be required	Depends on refresh process
Access and processing
Real-time suitability	Default only	Yes	Yes	Yes	Conditional	No
Read capability	Yes	Yes	Yes	Yes	Yes	Yes
Edit capability	No	Yes	No	No	No	No
Authentication	Database authentication	ArcGIS Enterprise authentication	ArcGIS Enterprise authentication	ArcGIS Enterprise authentication	ArcGIS Enterprise authentication	None for consumption
Utility Network licensing	Not required for database-only read	Required for Utility Network operations	Required	Required	Required	Not required for downstream consumption
Operational considerations
Resource-intensive workload	May affect operational database	May affect service capacity	Depends on change volume	Trace processing may be intensive	Export processing may be intensive	Strong fit
Data currency	Current Default data	Current	Current	Current	Depends on subnetwork state	Depends on refresh schedule
Principal limitation	Read-only and Default-oriented	Does not directly provide connectivity	Changes, not connectivity	Analysis result, not reusable extract	Depends on subnetwork processing and currency	Latency and synchronization
Best fit	Simple read-only Default queries	Feature queries, edits, and versioned access	Delta synchronization	Connectivity analysis	Reusable connectivity and derived network information	Resource-intensive reporting, analytics, or batch consumption

Decision matrix

Requirement	Preferred pattern
Connectivity	Trace
Authoritative connectivity	Export subnetwork
Delta sync	Differences API
Heavy analytics	Reporting database

Decision framework

Use the decision framework below to identify the default integration pattern before applying site-specific constraints. Start with the information the consuming system requires—feature attributes, network connectivity, derived network information, deltas, or analytical extracts—then evaluate data currency, version access, workload intensity, and the need for authoritative network results.

The framework is intentionally a starting point rather than a rigid rule. A solution may combine patterns—for example, Service/API access for operational feature queries, Differences API for delta synchronization, Export Subnetwork for authoritative connectivity, and a reporting database for high-volume analytics.

Architecture guardrails

• Default to Service/REST API access for supported operational integration.

• Use Differences API when the primary requirement is incremental or delta synchronization.

• Use Trace for on-demand connectivity analysis; use Export Subnetwork when a reusable, authoritative network representation is required.

• Use a reporting database to isolate heavy reporting, analytics, or batch-consumption workloads from the operational GIS.

• Treat direct database access as an exception for narrowly scoped read-only requirements; never use direct SQL to edit branch-versioned Utility Network data.

Integration patterns are not mutually exclusive; a complete solution may combine multiple patterns where different requirements apply.

Scenarios and recommendations

Scenario	Recommended strategy	Architecture rationale
Nightly analytics platform requires asset, subnetwork, and controller information	Reporting Database fed by scheduled Service/API and/or Export Subnetwork processes	Separates analytical consumption from the operational GIS and accepts scheduled data latency.
Operational system requires network connectivity to determine affected customers or devices	Trace for on-demand analysis; Export Subnetwork when authoritative reusable connectivity is required	Balances immediacy with the need for a validated, consistent network representation.
Material management system consumes approved design information from a named version	Service / API	Named-version access requires the ArcGIS service boundary and preserves version-aware workflow behavior.
Downstream system requires incremental synchronization of changed records	Differences API	Provides change-oriented synchronization without repeatedly extracting the full dataset.
High-volume reporting or data-warehouse workload does not require real-time data	Reporting Database	Protects operational service and database capacity while providing a consumption-optimized repository.

References

Reference	Source
System service	ArcGIS REST APIs
Anticipate and accommodate users	ArcGIS Enterprise
Best practices for system architecture	ArcGIS Enterprise