topic Re: Handling n:m Relationships Between Utility Network Feature Classes and Standalone Tables in ArcGIS Utility Network Questions

Handling n:m Relationships Between Utility Network Feature Classes and Standalone Tables

RoswithaLauterbach — Fri, 17 Oct 2025 16:32:28 GMT

I want to create an N:M relationship between several UN feature classes and a standalone table. I started in a local FGDB (ArcGIS Pro 3.5.3) to create the relationship classes (based on globalid) and made some connections. Afterwards, I exported the AssetPackage and deployed it to ArcGIS Enterprise 11.5. Now I encounter some issues:

In the exported Assetpackage, I noticed that the relationships are still present, but all actual relationships disappeared (I have the feeling that this is due to the fact that the table is not part of the UN FDS. However, it seems that it is not possible to create a table inside a FDS).
In the deployed UtilityNetwork, even the relationship classes themselves are not created.

Could you clarify whether n:m relationship classes between UN features and tables are currently supported? Does anyone has an idea what I could do to overcome this issue?

Re: Handling n:m Relationships Between Utility Network Feature Classes and Standalone Tables

gis_KIWI4 — Sat, 18 Oct 2025 06:21:41 GMT

@RoswithaLauterbach - I created a relationship class and table with our deployed UN as a test and it worked for me.

I can see the related data in ArcGIS Pro.

I am certain we can create additional tables and relationship classes post deployment and it works as intended as long as they relationship class is included in the map that is used to publish the service.

Something that caught me out was not including the relationship feature class while publishing the service.

Hope this helps 🙂

Re: Handling n:m Relationships Between Utility Network Feature Classes and Standalone Tables

RoswithaLauterbach — Mon, 20 Oct 2025 06:46:07 GMT

@gis_KIWI4 did you try exporting this as Assetpackage and re-deploy it? As long as I stay in a deployed UN, it works fine for me as well.

Re: Handling n:m Relationships Between Utility Network Feature Classes and Standalone Tables

PierreloupDucroix — Thu, 23 Oct 2025 04:44:18 GMT

Hello,

I used relationship classes in a mobile geodatabase, then exported them as an asset package and imported them into an enterprise geodatabase without errors.

Make sure you use the correct option in the asset package export toolbox, either the second or third:

Re: Handling n:m Relationships Between Utility Network Feature Classes and Standalone Tables

gis_KIWI4 — Thu, 23 Oct 2025 20:19:00 GMT

@RoswithaLauterbach - Apologies, I didn't get a chance to test it but what @PierreloupDucroix has suggested should work 🙂

Re: Handling n:m Relationships Between Utility Network Feature Classes and Standalone Tables

RoswithaLauterbach — Fri, 28 Nov 2025 07:12:37 GMT

I found a workaround. Export AssetPackage still steals me the actual links between 2 classes. But I created them by script again in the exported Assetpackage.

I was also today years old when I learnt that n:m relationships must be part of the map to publish a feature service to be properly read out in an Enterprise environment. Thats why assumingly I didnt see data after deployment. In fact the data was in the SDE database but not part of the feature service.

Thanks for all replies & helps anyway!

Re: Handling n:m Relationships Between Utility Network Feature Classes and Standalone Tables

RobertKrisher — Fri, 28 Nov 2025 13:13:11 GMT

@RoswithaLauterbach ah, that makes sense that the relationship wasn't showing up if you weren't including the M:N relationship in the map. M:N relationships, or any other form of attributed relationship, use a table to represent the related data. If it's not included in the service, then the application can't access the table that tells it which features are related.