Manually Triggering an Attribute Rule in Experience Builder

[Billy]

Hi,

I’m working with the following tools:

• ArcGIS Enterprise 11.3
• ArcGIS Pro 3.4.2
• Experience Builder in ArcGIS Enterprise
• Field Maps

This is part of an inspection workflow involving two feature classes (poles and handholes) with a relationship class to a single inspection table.

Workflow Overview:

• Field Workers (Field Maps): Conduct inspections and add records to the inspection table.
• Supervisors (Experience Builder): Monitor progress and make updates.

The symbology of poles and handholes is based on a "Status" field. I need an attribute rule that automatically updates "Status" to "Re-inspect" when the difference between "Next Inspection Date" and the current date is less than 30 days.

Ideal Solution:

• A scheduled process that periodically triggers the attribute rule across both feature classes.
• Alternatively, a manual option in Experience Builder that allows supervisors to select multiple features on a map and trigger the rule in bulk using out-of-the-box widgets.

Technical Details:

• The data is stored in an SQL Enterprise Geodatabase.
• The feature layer is published as a referenced layer to ArcGIS Enterprise (to support attribute rules).

What is the best approach to achieve this? Would an ArcGIS Python script scheduled in Windows Task Scheduler be a good option? Are there any Experience Builder methods (without custom widgets) that can help with manual triggering?

Any suggestions are appreciated!

Thanks.

[JeffreyThompson2]

Experience Builder is not the tool for this job.

A Scheduled Python task would work fine.

If you are not a programmer, you could use ModelBuilder and set it up to run on a schedule in Pro. 

[Billy]

Hi Jeffrey,

Thanks for the quick reply. 

Could you elaborate on how to use ModelBuilder to trigger the attribute rule?

Also, I think that the scheduling in Pro uses the Window Scheduler, how this workflow would work if I wanted that the scheduler triggering the Model or Python script were in a server machine, instead of my desktop.    

[JeffreyThompson2]

I'm going to cross-post your question to the Pro Board, so you can get some help from someone who spends more time on that program.

We have Pro installed on a server and routinely use it to run arcpy tasks, so it can be done.

[Joshua-Young]

As far as I know, you cannot schedule attribute rule execution. You would need to create a geoprocessing tool that loops through all records comparing the next inspection date with the current date and update the status where your criteria is met.

For AGE 11.3 and below, the official way to schedule tools is to use ArcGIS Notebook Server. The way we schedule a geoprocessing tool to run on a server involves installing ArcGIS Pro on the server and using that to schedule the tool to run. We use Python based tools and ArcGIS API for Python profiles to securely store and retrieve the credentials.

At AGE 11.4 and ArcGIS Pro 3.4 you can schedule a geoprocessing tool to run on a server by publishing the geoprocessing tool as a web tool and then schedule the web tool through ArcGIS Pro on your computer. https://pro.arcgis.com/en/pro-app/latest/help/analysis/geoprocessing/share-analysis/scheduling-web-t... 

[ShareUser]

Kind of depends on what the potential values of the Status field are.

If the values of the Status field are all based on the date since last, then one option would be to just use the Arcade in the symbology based on the Next InspectionDate field and current date.  WHEN the date difference is less than 30 days, symbolize it one color, if date difference is more than 30 days, symbolize it a different color.

This way it would all be handled by symbology, and there would be no need for scripts/att rules, etc. to update values in a field.

This would also work regardless of what software was used to make the updates.

R_

[Billy]

Hi RhettZufelt, 

The Status field is type "Short" and has a domain assigned with 3 options (Issues Found, No Issues, and Re-inspect). The value of this field is updated with an Attribute Rule in the inspection table, when the field worker performs an inspection (in Field Maps) there is follow-up question that is used to by the Attribute Rule to update the Status field in the parent feature. 

The symbology of the parent feature is based on this custom arcade expression:

var f_status = $feature.status

When(f_status == Null, 'Never Inspected', f_status == 1, 'Issues Found', f_status == 2,'Re-inspect', f_status == 3, 'No Issue', 'Others')

 I can include logic in this custom symbology to check for the difference between the last inspection and the next inspection dates and use it to return a value of "Re-inspect". The only question that I have is: what is the trigger for the evaluation of this custom symbology expression? Is it constantly being evaluated?

Regards. 

[ShareUser]

I thought you were mainly focused on symbology, so offered a suggestion that didn't take any 'calculations' and updates the symbology when you change the value(s), but also doesn't update any fields either.

Re-reading your post, it sounds like you want to update that field for ALL features in the featureclass so that any that match the past 30 days, it sets Status field to Re-inspect.

In a similar inspection process, since is Enterprise data, I set up an update trigger on the table in SQL Server Management Studio that calculates the value of the "Status" field each time there is an update made to that table.  Since this fires on the backend in SQL Server, the update is pretty much instantaneous any time you make changes to the table.  If you also allow adds to the data in the field, you could fire the trigger on update and add.  The same script could be used to not only update the Status field, but the last inspected and next inspection fields as well.

If 'waiting' for a change isn't frequent enough of an update, you could also copy the similar SQL to a scheduled job that updates daily, hourly, whatever frequency you need.

I use this on non-versioned and versioned - 'moving edits to base' with no issues.  Not sure if doing it this way would bloat out the versioning tables on full versioned data or not.  Would probably want to test that out if using full versioning.

If this isn't an option, I think you will be needing a scheduled GP Tool, python/notebook script as mentioned above.

R_