ApplyEdits without firing attribute rules and editor tracking on UN layers

[EstherSmith_Dev]

Hi all,

I have a simple query about Attribute Rules and Editor Tracking on UN layers. We have a bunch of immediate calculation attribute rules on Utility Network layers with editor tracking enabled. Attribute rules perform some data enhancements during edits made by the user in ArcGIS Pro.

We have a nightly process to perform some bulk calculations and we would like to not fire attribute rules and also not change editor tracking fields. We are using ApplyEdits REST call to perform the bulk updates. We would like attribute rules to not fire and also not change editor tracking values.

Is it possible? I would like to avoid Attribute Rule code to look for certain system user performing editing and not fire the rule if so. And it doesn't solve editor tracking problem.

I see Utility Network has UpdateSubnetwork tool that updates "SubnetworkName" field but does not fire attribute rules nor changes editor tracking values. So it must be possible somehow.

Thanks,

Vish

[emin-saka]

Hi EstherSmith_Dev,

If you want to avoid the rules and tracking altogether, you can directly use the database (e.g., PostgreSQL, MSSQL, etc.).

[MikeMillerGIS]

This is currently not possible.

[RobertKrisher]

We don't allow you to make the rules not fire, but you can create 'early exit' conditions that allow the rules to exit before they do any heavy analysis or editing. We have an item on our roadmap to allow you to refine when attribute rules so certain rules will only be triggered when specific fields are edited.

[emin-saka]

I routinely use this method when I do not want operations to be archived during the bulk update of attributes.

Enterprise 11.1
PostgreSQL 13.6
Pro 3.1.2"

[JoaquinMadrid1]

Just as Michael replied (not currently possible) and Robert recommended ("escape hatch") you can avoid triggering editor tracking under some circumstances. But, as you indicated, that does not resolve your problem.

If the business requirement to track specific edits must be satisfied (and that is a big if) then, and being aware of a huge hit in performance, you can think about the following approach.

First of all, accept that Editor Tracking is an internal capability within ArcGIS. As such, don't rely on it... you do not have control of it and any preconceived expectations that Editor Tracking should satisfy your business requirements should be discarded.

Instead, let Editor Tracking do its thing. Then, implement a mechanism where you take full control of how you want to track (or not) the execution of each AR. Add your own tracking fields to the schema and then build into your ARs logic with specific decisions on what to do depending on which user is running it, the day of the week, or whatever else you want...

As I said, this approach has huge impact on performance, but... if the business requirements justify it... this might be something to consider.