Prevent Infinite loops in Attribute Rules

By Hussein Nasser

Consider this table, we have two fields: group_name and common_name. The common_name must match for all rows within the same group.

We would like to create an attribute rule that ensures if the common_name is updated for a row, all rows within the same group receive the same name. This rule is straightforward; however, due to the attribute rules’ nature, updating the common_name will trigger the rule again. This repeated triggering can lead to attempting to update the same rows repeatedly, causing a cycle and potentially exhausting the Arcade engine execution instances. Resulting in the infamous error:

“The evaluation of attribute rules is cyclic or exceeds maximum cascading level”

Let us author the rule anyway to prove this.

An Attribute rule script that updates the same table, but fails with large rows.


//if the common_name hasn't change quit.
if ($feature.common_name == $originalfeature.common_name) return;
//grab the variables 
var g = $feature.group_name
var gid = $feature.GlobalID
var n = $feature.common_name
//look up all common_names same group and update them, we want to avoid updating the same feature and features with same name. 
var fs = Filter($featureset, "group_name = @g and globalid <> @gid and (common_name <> @n or common_name is null)") 
var updates = []
for (var f in fs) 
     push (updates, {"globalId": f.globalid, "attributes": {"common_name": n }})

return {
    "edit": [{"className": "main.mytable", "updates": updates}]
}

This rule works for groups of rows with a few rows but fails when there is a large number of rows to be updated.

To work around this issue, we need to differentiate between edits made by the user and edits made by the attribute rules. To achieve this, we can either add a new field or utilize an existing field in the table to indicate that the rule performed the update. During attribute rule execution we will set a specific value in this field (e.g. 1) to indicate the edit has been triggered from an attribute rule.

Subsequently, we will incorporate logic to revert the field value back to its original state, ensuring no impact on the data or schema.

I will introduce a new field called “t” and populate it with random values. It is important to note that these values will remain unchanged; they will temporarily alter during editing and then be reset back to their original values.

An Attribute rule script that updates the same table, works with any number of rows.



//if the common_name hasn't change quit.
if ($feature.common_name == $originalfeature.common_name) return;

//if this field has this value set, it means attribute rules has set it. We can use it to stop execution so we don't do further updates.
//We want to reset the original value of the field. 
//This field can be any existing field or a new field.
if ($feature.t == 1 && $originalFeature.t != 1 ) return {"result": {"attributes": {"t": $originalFeature.t}}}


//grab the variables 
var g = $feature.group_name
var gid = $feature.GlobalID
var n = $feature.common_name
//look up all common_names same group and update them, we want to avoid updating the same feature and features with same name. 
var fs = Filter($featureset, "group_name = @g and globalid <> @gid and (common_name <> @n or common_name is null)") 
var updates = []
for (var f in fs) 
     push (updates, {"globalId": f.globalid, "attributes": {"common_name": n , "t": 1}}) //set the field to 1 indicating attribute rules did the update. 

return {
    "edit": [{"className": "main.mytable", "updates": updates}]
}

And when we attempt to edit, you can see that the values update correctly without any errors, and the field we used to indicate attribute rule edits remains unchanged.

Ideally, we want to incorporate core functionality to achieve this within attribute rules (potentially within $editContext). We are still in the process of considering how to implement this. We will update the blog once this functionality is implemented. In the meantime, this workaround should suffice.

Edit 11/4/2026, starting from ArcGIS Pro 3.8, we have introduced a new property on $editContext called editTag which can be set during a DML edit return to distinguish an edit made by attribute rule from an edit made by a user. This now can be used to solve this issue without the workaround of adding a field. It also enables interesting scenarios, such as preventing a user from deleting a feature but only allow an attribute rule to delete it once certain conditions are passed.

You may download the sample geodatabase here.

Hussein Nasser

Product Engineer at Esri, Author of several GIS books and Software Engineering Content Creator on YouTube and a podcast host.

ArcGIS Blog

Prevent Infinite loops in Attribute Rules

Article Discussion:

Leave a Reply Cancel reply