Attribute Rules - Exclude from Application Evaluation

04-08-2021 10:30 AM
Esri Contributor
8 3 992

Attribute rules are scripts authored in Arcade and added to classes in the geodatabase to enforce constraints, calculate fields, query or edit classes in the same geodatabase. Many properties can be set while authoring attribute rules, the name of rule, subtypes the rule applies to, when to trigger the rule and yes Exclude from Application Evaluation. This option has raised many questions in the community so I thought I'd write a blog discussing the purpose of this property and when one should use it.

Attribute Rule Execution
Attribute rules are stored in the class, so wherever the geodatabase go, the rule goes with it. The rule always executes in the backend geodatabase datastore, whether you initiated the edit from Pro, Collector or Javascript API. Some applications are capable of understanding and executing the rule locally BEFORE the edit request is sent to the backend geodatabase datastore to be executed again.


Application vs Backend

It is important to differentiate between the application and the backend geodatabase workspace. ArcGIS Pro is an application and feature service, file or mobile geodatabase, enterprise geodatabase are the backend geodatabase workspace.

So if I add my filegdb class to Pro and edited the class, Pro can perform the edit locally before "sending" the edit request to the filegdb workspace. This concept is applied to any workspace, services, enterprise geodatabase, mobile geodatbase and file geodatabase.

You can see this behavior in Pro's attribute pane window while the Auto Apply option is turned off. Here is an example where we have an attribute rule that adds field a to field b and store the value in field c. The rule has allowed for application evaluation.



Exclude from Application Evaluation
When unchecked, "Exclude from Application Evaluation" property tells the application that its "safe" to execute this rule locally before sending the edit request to the backend. So you get the behavior like the attribute pane in place execution without the need to persist your edit to the backend to see the rules effects. Smart applications can look at this property and decide to leverage local attribute rule execution if it supports it. As for the time writing this blog, ArcGIS Pro is the only application that is capable of executing attribute rules locally.

Here is the same rule from before but with Exclude from Application Evaluation turned on. Noticed that local edits in the pane does not trigger the attribute rule until applying the edit to the workspace.








Constraint rules benefit the most from having the application execute the rule locally. If the application executes the constraint rule locally and finds that the rule is violated, an applyEdits request is never sent to the server since we know the request is going to fail there too. This saves on network bandwidth in certain case. Note that the constraint rule is always re-executed on the server side.

Another benefit of allowing the application to execute the rule locally is offloading heavy attribute rule compute to the application (when applicable) and only send the final result to the backend. The attribute rule has to be written in such a way to allow for the server to skip computation that has been already performed in the client. This way the server consumes less resources and editing throughput improves.


When to Exclude my Rule from Application Evaluation?

There are use cases where you want to exclude a rule from application evaluation here are a few.

Application doesn't support certain Arcade functionality
Even if the application is capable of executing attribute rules locally, not all Arcade functionalities are applicable for local execution. Examples are the attribute rules DML ability to edit other features, and working with sequences NextSequenceValue. Attribute rules that use these functionalities must be excluded from client evaluation.

Application doesn't have access to tables behind service

The application can sometimes have access to only a subset of classes of the backend geodatabase. Lets say a geodatabase has 3 classes class1,class2, class3. A feature service is published from this geodatabase but only class1 and class2 are included as layers. This means an application consuming the feature service only has direct access to class1 and class2 and NOT class3. If there is an attribute rule on class1 that was allowed to be executed locally (exclude from application evaluation was turned off) and that rule is querying class3, that rule will fail because the application wouldn't find class3 in its local workspace. You might have seen this error before "Arcade Error: Table not found"  followed by a guid, that error becomes clear once you understand what really is happening. For such cases you need to exclude the rule from local execution, sending the edit to the backend server will eventually execute on the server geodatabase workspace which has access to all classes.


Final thoughts
If we go back to when we first designed this, I would definitely pick another name for this property. Maybe Allow Application Evaluation?



Regular Contributor

Thank you for this great explanation!

This is a parameter that always confused me, but ArcGIS always told me when to check that box, so I didn't research it.


The attribute rule has to be written in such a way to allow for the server to skip computation that has been already performed in the client.

Sure, if I calculated a+b locally to improve throughput on the server, it would be senseless to have the server do it again. But how do you write such a rule? I don't see a way to tell the server that your example rule was already executed.

In my opinion, that should be part of the communication between client and server. When applying the edit, the client should tell the server it already did the job, so the server doesn't even have to start the execution to perform some checks built into the rule to see if it already executed.


Esri Contributor

Hey Johannes,

In most cases you can tell if the rule has been executed if a value has been set to a certain field. In our example if $feature.c has changed that indicates that the client has already performed and persisted the value to c and is now sending us the value of c along side a and b.

We released a global $originalFeature that would allow you to compare the original value of the field compared to the new value that is about to get set. So subsequent edits to a and b will produce new c values and you can compare if $feature.c is not equal $originalFeature.c then it means the client has already performed the calculation.

Of course this isn't straight-forward to implement and there are other gotchas as well to be discussed like making sure the client doesn't just mock with the value of c directly by making the field read only or hidden.

The compute in our example here is obviously trivial but the logic is applicable to complex Arcade expressions in a similar fashion

New Contributor

Thanks for this helpful illustration.

"If we go back to when we first designed this, I would definitely pick another name for this property. Maybe Allow Application Evaluation?"


My thought exactly!



About the Author
Software Engineer, Author of several GIS books and Software Engineering Content Creator on YouTube and podcast