Attribute Rules Triggering Fields in ArcGIS Pro 3.4

In ArcGIS Pro 3.4 we have introduced a new option for attribute rules: Triggering Fields. This new option allows you more control over exactly when attribute rules are triggered. In this article we will discuss how to use this new option along with why we felt it was important to add this new feature. Before we get too deep into this discussion, let’s quickly review how attribute rules work.

Background

Immediate calculation and constraint attribute rules, also known as immediate rules, have been a very useful tool for enhancing the editing experience since their release in ArcGIS Pro 2.1. Immediate rules execute when a user makes an edit (an insert, update or a delete), and based on the selected triggering event, the rule will run.

When an immediate rule is configured, you must specify a name and description for the rule along with which event(s) would trigger the rule. This rule would then be triggered every time one of the features with the configured rule was edited for the specified events.

This behavior is well understood for constraint attribute rules, but because immediate calculation rules allowed users to specify a field to be calculated, some users assumed that this meant the rule would only be triggered when that field was modified. Unfortunately, this is not the case, a feature will always trigger all its attribute rules for the events they are configured to fire on.

Updating a field using the calculate field geoprocessing tool or the attributes pane triggers any update-based attribute rules on the class for every updated feature. This can create a performance bottleneck, especially if you have complex attribute rules or many attribute rules configured. It has been a common request from users that we provide a way to allow certain edits to not trigger update attribute rules, without requiring the user to disable the attribute rules on the table.  Let’s look at an example .

Suppose you have a constraint attribute rule that prevents certain users from moving a feature once it is created. You might author the rule in this manner.

It is a simple rule and it works. If you try to move an existing feature the edit fails, try to update any other attribute and the edit succeeds. This is because when you update a feature, we always fire the attribute rule and provide the $feature as the current edited feature and $originalFeature as the state of the feature before the update. Arcade then takes over, parses the script, executes the code to compare the two geometries and then returns true or false.

If you do a calculate field on any other attribute field, for instance a field named notes or labeltext for a table that has 20,000 rows then you will be executing that Arcade expression 20,000 times, returning true every single time. This cost adds up, especially when we know that changing the attribute fields have no effect on the outcome of the geometry field constraint rule. And this is why we created triggering fields.

Attribute Rules Triggering Fields

When creating an immediate attribute rule that includes a triggering event for update, you are presented with a list of fields. The triggering field list allows you to further refine the update event to only trigger when the value in specific field(s) change. By default, all fields are selected, meaning that any update to the feature will trigger the attribute rule. This was done for backward compatibility to older ArcGIS Pro clients. You should consider this list and remove any fields that you don’t want to trigger the rules.

You can also use the Add from script button which will analyze the Arcade script and adds all the fields used by $feature in the script. You can of course make additional changes as you see fit.

Once you set the list of triggering fields, save the rule. The rule will now only run if any fields from the list of triggering fields are updated. Let’s re-examine our previous example and update the rule to only trigger on a shape field edit using the triggering fields functionality

Now with that rule setup, let us do an update on the notes field on both Pro 3.3 and 3.4 and compare the performance of updating the field for 20,000 features.

Notice that making this one change on this one attribute rule causes the operation to complete in 3.4 in less than 5 seconds, while it takes over a minute in 3.3! This is why we encourage users to consider implementing triggering fields on any new attribute rules and if you are upgrading form an earlier release you should see if you can apply this configuration to any of your existing rules. Remember, these effects are cumulative with every rule that is triggered so the more rules you have or the more complex your rules are, the more benefit you’ll see from configuring triggering fields.

Update subnetwork

Update subnetwork is a utility network tool that sets the subnetwork name to all features discovered in the path of the subnetwork trace. When a tier has eventing turned on, this operation can slow down significantly especially when attribute rules are configured on update. For those interested in the details, read the Understanding Subnetworks: Events article on the Esri Community site.

If the utility network source classes have update-event attribute rules, the rules will trigger during update subnetworks, even though updating the subnetwork name does not necessarily have a direct effect on the outcome of the rules.

With triggering fields in 3.4, users can exclude the subnetwork name, isconnected, and any propagated fields from the triggering fields. These fields are all modified by the update subnetwork process, so excluding them from your triggering field list will ensure your attribute rules won’t fire during update subnetwork. This allows customers with attribute rules who use eventing to greatly improve the performance of update subnetwork.

Conclusion

In this blog we learned about the new Attribute Rules triggering fields in ArcGIS Pro 3.4, which allows immediate calculation and constraint rule to scope their update to a subset of fields. With attribute rules triggering fields you can improve the scalability of your system and improve the overall performance when editing, especially in large edits. To learn more about attribute rules check out the help resources.

To learn more about attribute rules check out the related help topics and the materials provided on the Geodatabase Resources Hub