Best practices for managing and validating Utility Network associations in telecom (FTTH) after migration to SDE

[stenglasdeveloper]

Hi all,

I’m currently working on a telecom (FTTH) implementation of the ArcGIS Utility Network, where we have successfully migrated and validated our data into an enterprise geodatabase (SDE) within ArcGIS Enterprise.

The network includes typical fiber components such as conduits, cables, fibers, splice points, ports, and customer endpoints. As expected, most of the critical relationships—such as containment (for example conduit > cable > fiber) and connectivity (for example port > fiber > splice)—are stored as network associations rather than standard feature class attributes.

We can work with these associations in ArcGIS Pro without issues (for example through the Modify Associations pane and tracing), and we can also see the association records directly at the database level in the un_*_associations table.

What I was expecting, however, was that after publishing the data and consuming it in web maps, it would be possible to explore these relationships in a more user-friendly way — for example to browse containment or connectivity hierarchies similarly to how related network information can be inspected in ArcGIS Pro.

So the main question is not how to access associations technically, but rather what the recommended best practices are for making them usable outside of ArcGIS Pro, especially for QA, debugging, and integration workflows.

Specifically, I would like to understand:

• What are the recommended approaches for querying and analyzing associations outside ArcGIS Pro in telecom/FTTH implementations?
• Are there supported or recommended patterns for exposing associations in a more relational or “attribute-like” structure (for example database views, derived layers, or services) for QA and operational use?
• How do you typically validate complex fiber paths in production environments after migration or data loading?
• What tools or workflows (ArcPy, REST, tracing, custom scripts, database views, etc.) are commonly used for automated validation and day-to-day work with telecom network topology?

The goal is to establish scalable, automation-friendly workflows for managing, validating, and interpreting associations in a production telecom environment, without relying solely on the ArcGIS Pro UI.

Any insights, recommended patterns, or real-world experience would be highly appreciated.

Environment: CUNF 1.6, ArcGIS Pro 3.6, ArcGIS Enterprise 12.0, PostgreSQL 17.6

[RichRuh]

Hello,

We have a blog post that describes how to configure Map Viewer to work with utility networks. The blog post doesn't describe that you can also configure popups to allow navigating relationships. There's similar tools in Web Editor as well, and we're in the process of adding more functionality to Experience Builder.

If you have access to DevSummit recordings, I've helped present a session titled "Beyond the Desktop: WebGIS and the Utility Network."

If you are an application developer, we also provide a JavaScript API for the utility network, and of course, the underlying REST API is also available. 

Is this the kind of information you're looking for?  Let me know if you have further questions,

--Rich

[RichRuh]

We also have an entirely new telecom domain network that will ship with Pro 3.7 and Enterprise 12.1 later this year. It's currently in beta.

[stenglasdeveloper]

Thanks Rich, this is helpful.

I’m already familiar with Map Viewer configuration, popups, and Web Editor capabilities. However, in my telecom (FTTH) use case, I’m finding these approaches still limited for deeper inspection, QA, and debugging of network associations.

I’ve started exploring an alternative approach using SQL directly on the Utility Network associations table, building derived views (for example translating containment relationships like StructureLine > StructureEdgeObject into attribute-like structures and hierarchical chains).

I’m also planning to compare this approach with REST/JavaScript API workflows.

Have you seen this kind of database-level analysis/derived view pattern used in practice, or is the recommended direction always through REST/JS API and trace services?

PS: I’m aware of the new telecom domain network currently in beta and I’m planning to evaluate it once the general release becomes available later this year. Do you have any more specific timeline or expected release window for this?

[RichRuh]

I'm the product owner for the Utility Network JavaScript API, so I'd love to know more about what you want to do that isn't possible with that API.  If you don't want to share this information publicly, please reach out via e-mail at rruh@esri.com.  

Pro and Enterprise should ship later this spring. I'm not on those teams, so don't want to speak for them with exact dates.

--Rich

[RobertKrisher]

Building live SQL views directly on the branch versioned data is not recommended, but if you had a read-only instance where you materialized the contents of the views that would be a more performant approach. Doing this requires a strong understanding of the branch versioning model as well as a strong understanding of how associations are represented in domain networks AND telecom domain networks. It would be very difficult to write a SQL view that could do all that in an efficient manner, on the fly.