topic Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890 in ArcGIS Utility Network Questions

Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

JohnGoat — Tue, 03 Mar 2026 14:43:37 GMT

Hello,

I am working within the same Tier where two different Subnetwork Controllers generate two different SubnetLines:

1724 → Yellow SubnetLine

1734 → Blue SubnetLine

Both subnetworks exist in the same tier but are created from different subnetwork controllers. For clarity, I will refer to them as Yellow (1724) and Blue (1734).

Scenario

I place a starting flag on a feature.

I run a Downstream Trace.

My intention is for the trace to stop at devices where:

OS (Operational Status) = Open
(Configured as an Attribute Filter Barrier)

Additionally:

NS (Normal Status) is used as a Tier Condition Barrier.

Observed Behavior

The trace starts within the Blue subnetwork (1734).

It then transitions into the Yellow subnetwork (1724).

If there is a device ahead with OS = Open, the trace correctly stops at that device.The tracing changes from the blue line to the yellow line, and the tracing process stops at OS=Open.

However, if there is no device with OS = Open ahead and the trace encounters the Yellow Subnetwork Controller, the trace fails with:

ERROR 001890: Invalid subnetwork connectivity, multiple subnetwork controllers with different subnetwork names found.

Expected Behavior

Even if no OS = Open device exists ahead, I expect the trace to stop when it reaches a Subnetwork Controller belonging to a different subnetwork.

I also tried adding a Filter Barrier:

Is Subnetwork Controller = True

However, the trace still returns the same error instead of stopping at the controller.

Question

Why does the trace continue into another subnetwork within the same tier instead of stopping?

Why does adding Is Subnetwork Controller = True as a filter barrier not prevent the ERROR 001890?

Is this behavior by design when tracing across multiple subnetworks within the same tier?

What is the recommended configuration to ensure a downstream trace:

Stops at OS = Open devices, and

Stops when encountering a different subnetwork controller,
without generating ERROR 001890?

Any clarification on correct trace configuration in this type of multi-controller tier setup would be greatly appreciated.

Thank you.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

MikeMillerGIS — Tue, 03 Mar 2026 10:53:03 GMT

Is the device between the blue and yellow a subnetwork controller? Can you verify the blue line is connected to a different controller than the yellow line?

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

JohnGoat — Tue, 03 Mar 2026 11:26:45 GMT

The device located between the Yellow and Blue lines is not a Subnetwork Controller. This device is positioned at the boundary between the two subnetworks.The Blue and Yellow lines are connected to different Subnetwork Controllers. Their names are labeled on the map:

1734 represents the Subnetwork Controller name for one subnetwork.

1724 represents the Subnetwork Controller name for the other subnetwork.

So although the subnetworks are adjacent at that device, they are fed by separate Subnetwork Controllers.

@MikeMillerGIS

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

MikeMillerGIS — Tue, 03 Mar 2026 11:33:23 GMT

Then you need to define a condition barrier that separates those two subnetworks at that device. You need a condition barrier for both NS is open or OS is open.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

JohnGoat — Tue, 03 Mar 2026 12:19:42 GMT

If I define an Open condition barrier for both NS and OS, the trace correctly stops at that device.

However, my intention is different. I want the downstream trace to continue past that device and proceed all the way to the Yellow subnetwork’s Subnetwork Controller.

The label is probably unreadable.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

MikeMillerGIS — Tue, 03 Mar 2026 12:22:43 GMT

You will need to open another device to isolate the yellow subnetwork from that section then. In the current state, the network sees two subnetworks on that line. Meaning it is energized from both directions.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

JohnGoat — Tue, 03 Mar 2026 13:21:34 GMT

Yes, the device is energized from both directions, and with the current configuration I am able to continue the trace from the Blue line into the Yellow line.

The issue occurs only when there is no device on the Yellow line with OS = Open ahead.

In that case, the downstream trace continues all the way to the Yellow subnetwork’s Subnetwork Controller, and at that point the trace fails with the error.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

MikeMillerGIS — Tue, 03 Mar 2026 13:58:10 GMT

The only other way is added a directional device so the blue controller cannot trace to the yellow controller. Something like a network protector right after the yellow controller.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

RobertKrisher — Tue, 03 Mar 2026 14:03:05 GMT

This is working as designed. If you cannot have two subnetworks with different names connected to each other. If in the field this area is always fed by the two sources, then they should have the same subnetwork name. If they are only fed by one or the other, then model the device as open to separate the networks. Trying to artificially separate the networks with a closed device won't really work, as you'll see below.

A feature is only a subnetwork controller if it belongs to an asset type that has all the correct configuration (subnetwork category, directional terminal config, associated with a subnetwork definition in the controller role) AND you have used the modify subnetwork controller tool to enable it as a subnetwork controller. If you want that trace to stop at the "possible controller" when it's CLOSED and NOT a subnetwork controller you could add a condition barrier to stop at features that have the Subnetwork Controller network category (which may have unintended consequences) or you could use a network category specific to this situation.

The problem with doing that is that if this 'possible controller' will ALWAYS stop tracing, regardless of state or configuration. Which means that if you ever wanted to feed the area from the yellow source instead of the blue source you'd need to remove the device.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

RobertKrisher — Tue, 03 Mar 2026 14:24:56 GMT

This is a known limitation of the way that subnetworks are modeled. To work around the issue you can model an open point (or other barrier) to separate the two subnetworks, which you have already discovered. Please log an issue and get yourself associated with BUG-000173401.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

JohnGoat — Thu, 05 Mar 2026 08:50:15 GMT

Hi again, @RobertKrisher @MikeMillerGIS

It would be better if I explained it in a little more detail.

UN Version 7

ArcGIS Pro 3.5.5

OS = Operational Status
NS = Normal Status

The Blue and Yellow represent two different Subnetlines within the same Tier Rank, fed from different sources.

These two fe eders are separated in the Subnetwork Definition by a Condition Barrier defined as NS = Open.
Inside Substation 5400, in Cell 1, there is a Circuit Breaker with NS = Open. With a normal Downstream Trace, the trace stops at this location.

Trace 1

As shown in the screenshot, when a Condition Barrier with OS = Open is used, the trace stops at the Circuit Breaker located in Cell 2.

In this case, the trace crosses from the Yellow Subnetline to the Blue Subnetline, and then stops at the Condition Barrier.
This is the expected result.

Trace 2

In this scenario, the Operational Status (OS) of the Circuit Breaker located in Substation 5400 – Cell 2 was changed to Closed.

Additionally, Is Subnetwork Controller = True was added as a Filter Barrier, because after the trace crosses from the Blue cable to the Yellow cable, there is no Circuit Breaker ahead and the energy continues toward the Subnetwork Controller.

However, in Trace 2, even though Is Subnetwork Controller = True is defined, the trace does not stop and instead returns the following error:

ERROR 001890: Invalid subnetwork connectivity, multiple subnetwork controllers with different subnetwork names found.

My question is:
Is this behavior working as designed, or could this be considered a bug?

In our network operations, we use the Normal Status (NS) field for permanent switching configuration.
The Operational Status (OS) field is used to manage temporary switching operations during the day (such as outages, maintenance, or repairs).

At the end of the day, the Operational Status values are synchronized with the Normal Status values. However, during the day we intend to run our trace operations using this configuration.

Thanks,

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

RobertKrisher — Thu, 05 Mar 2026 14:10:50 GMT

@JohnGoat Filter barriers don't affect traversability, only the results that are returned. This means that the first controller is able to trace to the second controller, which is giving you that error. If you change th filter barrier to a condition barrier, it should work.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

JohnGoat — Mon, 09 Mar 2026 05:34:48 GMT

@RobertKrisher No, it still doesn’t work. The trace should stop when it encounters Is Subnetwork Controller = True, but instead it throws this error. Since the trace continues past that point and reaches the next controller, it returns the error.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

RobertKrisher — Mon, 09 Mar 2026 13:18:03 GMT

If the device that is acting as a barrier is a subnetwork controller (is subnetwork controller = true), then the trace has gone too far, and you will get an inconsistent subnetwork name error.

If you want the trace to stop at features that can be subnetwork controllers, but aren't enabled as subnetwork controllers you would set the condition barrier to be on the Subnetwork Controller category.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

JohnGoat — Tue, 10 Mar 2026 12:16:27 GMT

@RobertKrisher

I also tried using a Condition Barrier with Category = Subnetwork Controller, but I still receive the same error. It doesn’t seem to make any difference in this case.

I think this might be a system limitation or possibly a bug. If a trace encounters a different Subnetwork Controller within the same Tier, we should be able to stop the trace using a Condition Barrier or a similar configuration.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

RobertKrisher — Wed, 11 Mar 2026 13:48:39 GMT

This subnetwork category condition barrier should be in addition to any other condition barriers you have for the normal or operational state. Otherwise, the system will not treat the other switches as open. IF you want to see the path between the two controllers, switch the trace to be a shortest path trace and put starting locations at each controller.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

JohnGoat — Thu, 12 Mar 2026 06:16:58 GMT

@RobertKrisher I do not want to see the path between the two controllers; I want the trace to stop at the controller. If I manually set a barrier on the controller from the map using Set Barriers, the trace stops as expected. To me, this suggests that the Condition Barrier function is not recognizing the definitions Is Subnetwork Controller = True or Category = Subnetwork Controller.

Also, for a Shortest Path trace you need two starting points. In my case, I don’t know where to place the second starting point, so this is not a viable option for us.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

RobertKrisher — Fri, 13 Mar 2026 14:24:46 GMT

@JohnGoat

If the device you put the barrier is an enabled subnetwork controller, then this is the expected behavior and you will need to open a case with support and create an enhancement request.

Working through detailed requests like this on the community site is difficult, particularly when you are skipping over some of my steps and instructions. Because I don't have access to your data I may ask you to do strange things (like run a shortest path between the two controller) so I can better understand the topology we are dealing with.

At this point I feel this is not an issue we can resolve through discussions like this. Please log a case with support and have them work through the issue with you.

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

RobertKrisher — Thu, 30 Apr 2026 14:42:38 GMT

If you remove the related records parameter from your script does it fix the publishing error? Did you try changing the parameter order?

Re: Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

JohnGoat — Sat, 02 May 2026 18:23:32 GMT

@RobertKrisher Yes I removed the related records parameter, but the error persists. I've tried every combination of order, but it hasn't worked.