Isolation Trace - Skip Certain Control Valves Based on Attribute / Ground Condition

[DonSanjeewaErangaJayaweera]

Hi everyone,

I’m working with a Water Utility Network in ArcGIS Pro 3.5 and trying to implement a custom isolation trace behavior.

Requirement

We have control valves with a source attribute called:

GroundCondition

If:

GroundCondition = "High Speed Road"

then the isolation trace should NOT stop at that valve and should instead continue to the next valid control valve.

Operationally, these valves are difficult/inappropriate to use for isolation.

What I Tried

1. Added a new field

IsolationEligible

Values:

• 1 = valid isolation valve
• 0 = should be skipped

Calculated using:

IIF(Upper(Trim($feature.GroundCondition)) == "HIGH SPEED ROAD", 0, 1)

2. Added Utility Network network attribute

Created a network attribute from IsolationEligible.

3. Updated Isolation Trace configuration JSON

I added IsolationEligible as a network attribute condition in:

• conditionBarriers
• filterBarriers

Example:

{
  "name": "IsolationEligible",
  "type": "networkAttribute",
  "operator": "equal",
  "value": 1,
  "combineUsingOr": false,
  "isSpecificValue": true
}

Observed Behavior

Connected Trace

Picks up the new field but behavior is not consistent 

The trace stops devices where:

IsolationEligible = 0

Isolation Trace

Does NOT work as expected.

Observed behavior:

• Trace still stops at first control valve even when IsolationEligible = 0
• OR trace returns:

WARNING 002535: arcgis un trace warning

with no results.

Important Finding

After investigating Utility Network properties, I noticed:

Control Valve -> Category = Isolating Device

It appears the Isolation Trace solver inherently treats these valves as valid isolation candidates before the custom network attribute condition is evaluated.

This seems different from how Connected Trace behaves.

Steps followed:

1. Created a new field along with a domain
2. Added auto Population Rule to make sure new data updates accordingly 
3. Updated all existing control values with correct logic (Calculate field)
4. Add Network Attribute
5. Validated network topology

I introduce this IsolationEligible field to Supply Device FC and but values were calculated only for Control Value  subtype which is the isolating device. For other types the value is "Null"

Questions

1. Has anyone implemented similar “skip this valve during isolation solving” behavior?
2. Is there a supported way to influence Isolation Trace candidate valve selection using custom network attributes?
3. Is using separate asset types/categories the recommended pattern?
4. Are there other approaches people have successfully used?

Any guidance or real-world patterns would be greatly appreciated.

Thanks!

[gis_KIWI4]

Adding the condition barrier AND in FilterBarrier isn't going to be benficial.
If you want the trace to stop at a certain object then that condition belongs in the FilterBarrier sections.

You should use a AND condition in your FilterBarriers section.
So your condition might look something like Category = Isolating Device AND IsolationEligible = 1

This will mean that any Control Valve that is not on HighSpeedRoad will be treated as a Isolating Device. 

As a crude test, I tried this on our electric Network. 
I can confirm it skips any devices that are not subnetwork controllers and selects the one where ISSUBNETWORKCONTROLLER = True

[DonSanjeewaErangaJayaweera]

Thank you  for your reply.
From the start I was using filter barriers. 

Now I tested again using the exact condition:

Category = 'Isolating Device' AND IsolationEligible = 1

but the behavior remained the same. May be he filter barrier logic may only evaluate built-in/system network attributes and ignore custom-created ones.

DO you know whether custom network attributes are officially supported in filter barrier conditions for tracing/isolation workflows? If they are supported, are there any additional requirements such as indexing, schema registration, or publishing settings that need to be configured?

[RobertKrisher]

Once you've created the network attribute you must assign it to each field/class you want to associate with that network attribute then you must ensure that the field on each class is populated with the desired values.

[DonSanjeewaErangaJayaweera]

Hi RobertKrisher,

Thanks for your inputs.
Just to confirm that I have already done below steps for this testing.

1. Created a new field along with a domain
2. Added auto Population Rule to make sure new data updates accordingly 
3. Updated all existing control values with correct logic (Calculate field)
4. Add Network Attribute
5. Validated network topology

I introduce this IsolationEligible field to Supply Device FC and but values were calculated only for Control Value  subtype which is the isolating device. For other types the value is "Null"

[gis_KIWI4]

@DonSanjeewaErangaJayaweera - network attributes are supported in the trace.
You shouldn't need to re-index or anything.

Are you able to share some screenshots of the devices being selected and the trace tool. That might help troubleshoot this further. 

[RobertKrisher]

A condition barrier will prevent the trace from identifying sources, while filter barriers are used to identify candidate features to act as isolation equipment. For what you are trying to do, you want to configure a filter barrier. I'm just restating what @gis_KIWI4 said in a way that makes sense to me.

To be clear, there is no 'internal logic' or behavior of the UN with regards to condition barriers/filter barriers. We will only evaluate the attributes that are configured in the form. There are default condition barriers that are included in subnetwork definitions that are populated when you configure an isolation trace, but these are configurable and can be modified at will so therefore are not 'internal'.