Most growing water utilities in the Southwest are running their GIS on ESRI ArcGIS — either the traditional enterprise geodatabase model or the newer ArcGIS Utility Network. If your utility has invested in a water network model in ArcGIS, that model contains the asset geometry and attribute data that is the foundation of any serious pipe analytics. Getting that model connected to live telemetry is the integration work that makes analytics possible. This post is a specific, technical walkthrough of how that connection works for the Watsynq deployment.
A note on scope: this describes the integration architecture for utilities using ArcGIS Utility Network (ArcGIS Pro 2.6+, or ArcGIS Enterprise 10.8+) or ArcGIS for Water (the utilities-specific template). The traditional geometric network model in ArcMap is being deprecated by Esri; if your utility is still on the legacy model, the general data flow is similar but some of the API specifics differ. Contact your integration engineer if you're unsure which model you're using.
Step 1: Export segment geometry and attributes from ArcGIS Utility Network
The starting point is a feature class export of your distribution main network. Watsynq needs, at minimum: pipe segment polyline geometry (WGS84 or NAD83 — we'll reproject if needed), asset ID (the unique segment identifier in your geodatabase), installation year (field name varies by implementation — typically INSTALLYEAR, INSTALLDATE, or YR_INSTALL), pipe material (MATERIAL), diameter (DIAMETER in inches), and lining presence if recorded.
The export can be accomplished via ArcGIS REST API (using the Feature Layer query endpoint with returnGeometry=true and your attribute fields in the outFields parameter), or via a direct geodatabase feature class export to file geodatabase or shapefile format. The REST API approach is preferred for ongoing synchronization (we poll for updates on a configurable schedule); the file export is acceptable for the initial onboarding data load.
If your ArcGIS installation is on ArcGIS Enterprise (ArcGIS Server), the Feature Service URL format is:
https://[your-server]/arcgis/rest/services/WaterNetwork/FeatureServer/[layer-id]/query
?where=1=1
&outFields=OBJECTID,ASSETID,INSTALLYEAR,MATERIAL,DIAMETER,LINING
&returnGeometry=true
&f=geojsonYou'll need to provide Watsynq with a service account that has read access to the Feature Service. This service account should be scoped to read-only access on the water network feature service only — not broad GIS administrator access. Create a named account in your ArcGIS Enterprise portal with the minimum necessary permissions.
Step 2: Connect break event records via CMMS or GIS work orders
Break event history is as important to the risk model as the pipe attributes themselves. If your work order system (Maximo, Cityworks, Hansen, or equivalent) is integrated with ArcGIS — as is common in utilities using Cityworks or the ArcGIS integration for Maximo — break event records may already be stored as GIS feature classes or related tables with geometric location data. In that case, the break record export can follow the same REST API pattern as the pipe geometry export.
If break events are in a standalone CMMS with no GIS linkage, a CSV export with address or coordinate location is the starting point. Watsynq's integration pipeline performs a spatial join to match break records to pipe segments within a configurable tolerance (typically 15 meters for address-geocoded records). This matching step requires a review pass by your GIS analyst to confirm the matches for ambiguous cases — in dense urban corridors with multiple parallel mains at similar addresses, the spatial join alone is insufficient for reliable matching.
Step 3: SCADA historian connection for pressure telemetry
Watsynq connects to your SCADA pressure historian via the AVEVA PI (formerly OSIsoft PI) REST API (PI Web API), or via OPC-UA for systems that expose an OPC server interface. Both connection methods support read-only historian queries — Watsynq requests time-series data for specified tag names (your pressure sensor tag IDs) across a specified time window.
You'll need to provide a list of PI tag names for the pressure sensors in your distribution system, along with the coordinate location or zone ID of each sensor. This is typically a list your SCADA engineer can export from PI System Explorer or the tag configuration database. The sensor-to-GIS-segment mapping (which sensors are hydraulically relevant to which pipe segments) is built by Watsynq's integration engineer during the onboarding phase, using the Utility Network topology and sensor coordinate data.
The PI Web API connection requires your PI Server to be reachable from the Watsynq cloud infrastructure. Most utilities implement this via a site-to-cloud VPN tunnel or a PI Relay/PI-to-PI forwarding configuration that keeps the PI Server on the OT network while exposing read-only query capability through a DMZ relay. Your SCADA vendor or PI system administrator can advise on the appropriate architecture for your OT/IT network boundary configuration.
Step 4: Risk score writeback to ArcGIS feature layer
Once the risk model is running, Watsynq writes the daily-updated risk scores back to a hosted feature layer in your ArcGIS Enterprise portal (or ArcGIS Online, if you prefer that hosting model). The writeback creates or updates a feature class named WatsynqRiskLayer (configurable) with columns for segment_id, risk_score (0–100), risk_tier (High/Medium/Low), last_updated timestamp, and a human-readable primary_risk_driver field describing the dominant feature contributing to the score.
This hosted feature layer can then be consumed in ArcGIS Pro, ArcMap, or ArcGIS web maps like any other hosted layer. Your field crews can view the risk score map in ArcGIS Field Maps on their tablets during inspection activities. The layer can also be used as input to ArcGIS Network Analyst or ArcGIS Spatial Analyst for capital planning workflows — overlaying the risk score against planned capital project corridors, for example, to identify opportunities for replacement bundling.
Common integration issues and how to resolve them
Three issues account for the majority of integration delays in ArcGIS-based deployments:
Asset ID mismatches: The OBJECTID or GlobalID used as the primary key in ArcGIS is often not the same as the asset ID recorded in the CMMS break records or on the SCADA sensor tags. We build an explicit ID crosswalk during onboarding, but the crosswalk requires a human review step that can take 3–5 business days if the utility's GIS and SCADA teams haven't previously coordinated on asset ID conventions.
Feature Service authentication: ArcGIS Enterprise token-based authentication tokens expire and require renewal. We use OAuth 2.0 service account credentials, not session tokens, to avoid expiry issues — but this requires the service account to be configured for OAuth access in your portal, which some utilities restrict in their default security policy.
Topology errors in the Utility Network: If your Utility Network has dirty topology (unvalidated topology errors from incomplete editing sessions), the connectivity analysis used to build the segment-sensor association table may produce incorrect results for the affected segments. Run a full network topology validation in ArcGIS Pro before the initial data export; it's good GIS hygiene regardless of the Watsynq integration.
The integration architecture described here has been stable across deployments on ArcGIS Enterprise 10.8–11.x. Esri's ArcGIS Utility Network is under active development; if your utility upgrades ArcGIS Enterprise major versions during the Watsynq contract period, notify your integration engineer in advance to confirm API compatibility.
Nadia Vasquez is Head of Data Science at Watsynq. ArcGIS is a registered trademark of Esri. The integration described in this post uses Esri's public REST API; this article does not imply an endorsement or partnership with Esri.