Allow Editing on Fields with Arcade Calculated Expressions

2781
29
08-22-2023 04:25 PM
Status: Open
Labels (2)
JoshuaFlickinger
New Contributor III

Idea

Allow fields to remain editable when an Arcade Expression is used to calculate them.

Reasoning

Calculated expressions are great at improving efficiency in field operations, but in advanced use cases they don't always work the way I expect them to.  Some of it may be user error on my part, but because I can't rely on my expressions, I generally end up not using them.  Allowing the field to remain editable would increase usability in the shoulder cases where my expressions fail to return expected results.

Example

I provide GIS support for a forest monitoring crew.  The crew maps trees in plots and fills out a bunch of information about each tree.  To keep track of trees over time, each tree gets a unique identifier.  I wrote an Arcade expression to create the tree ID on the fly whenever a new tree is mapped.  The expression uses a geometry intersect to determine which plot the tree is in.  Then it counts all the existing trees in that plot and adds 1 to the number of existing trees.  Finally it returns the plot and tree number in a nicely configured format. 

Works like a charm, when it works.  Unfortunately, it doesn't work when the accuracy threshold for data collection hasn't been met.  In these cases, no point exists to do the geometry intersect, but arcade still proceeds with the calculation.  It looks like it errantly picks the first plot in the list by default and returns me a blatantly wrong ID.  Would be great if I could go back in and manually input the ID in these cases.

29 Comments
LindsayRaabe_FPCWA

@AlixVezina Awesome! Works a treat. Copied my comment from the Blog post here. 

Used it to enable manual override of a calculated location name based on intersecting features. 

Calculated:

LindsayRaabe_FPCWA_0-1711405632605.png

Entered Manually:

LindsayRaabe_FPCWA_1-1711405657198.png

 

Now that this workaround is in place, I have ANOTHER idea to add to the mix - Dynamic lists generated using calculated expressions (assuming no one else has already posted something like this). 

LindsayRaabe_FPCWA

Found what looks like a small bug in Experience Builders Edit widget and Field Maps. In Experience Builder, the "Switch" option isn't loading by default until you click in the box and select a value from the list, then it changes to the switch in the "No" position (even if you selected Yes). See below screenshots. In Field Maps, it doesn't load as a Switch at all - just a drop down list. It also seems the default "No" value isn't being populated either. 

LindsayRaabe_FPCWA_0-1711419757395.png

Selecting "Yes" from List

LindsayRaabe_FPCWA_1-1711419836239.png

Then changes to Switch in "No" position

LindsayRaabe_FPCWA_2-1711419854790.png

Which can then be toggled to "Yes"

LindsayRaabe_FPCWA_3-1711419878117.png

 

 

DebHSF
by

Thanks @AlixVezina . This is a good workaround IF you are able to easily incorporate the extra toggle field(s) into the layer schema. Unfortunately that's not always easy for us just due to the way the data is managed. It also means that you are adding extra fields to a potentially already long list of fields in a dataset.

So please can this Idea be kept open to implement something at the Field Maps configuration level rather than the schema level.

AlixVezina

@DebHSF Thank you for your post! Yes, I understand and agree that this workaround is not ideal and that a schema change is most definitely not preferred, and we're looking into providing better options for this workflow for the future.

AlixVezina

Hi @LindsayRaabe_FPCWA ,

I am not able to observe the issues you've described both for Experience Builder or Field Maps.

Experience Builder (in ArcGIS Online)

AlixVezina_0-1711460426422.pngAlixVezina_1-1711460435478.png

Field Maps

Image.png

Is there any further information you are able to share? Is anything different with your setup?

 

LindsayRaabe_FPCWA

@AlixVezina Screenshots below show the smart form config in the webmap, again in Field Maps Designer and the Edit Widget config in Experience Builder. 

LindsayRaabe_FPCWA_0-1711499728335.png

LindsayRaabe_FPCWA_2-1711500335020.png

 

LindsayRaabe_FPCWA_1-1711499770463.png

I've noticed that there's a slight difference between the form config in the Webmap and Field Maps Designer though. FMD shows the default value property (greyed out) but webmap config doesn't. But that got me thinking, the other difference is FMD also has the Templates view (which the webmap doesn't) and when I looked in there as prompted by the little warning message below the default value section, I needed to update the template to include the new fields. Once I added those (and thus the default "No" values), it started working properly in Experience Builder and Field Maps! The only exceptions here are existing data that when edited, still don't have a value and it goes back to the "No value" combo box display (but I'll go through and update all features with "No" to get around that). 

LindsayRaabe_FPCWA_5-1711501844230.png

Lesson learnt - do smart form stuff in Field Maps Designer. 😑🌴

AlixVezina

@LindsayRaabe_FPCWA ,

Thank you for the details, and nicely done getting to the bottom of this one!

Yes, a default value needs to be set for the switch to display as expected. If the default value was not defined when the field was created, it is possible to do it from the Templates. Authoring and managing Templates is not yet supported from within the Map Viewer, but it is planned for an upcoming release. Once it's implemented, hopefully this workflow will be more straightforward.

LindsayRaabe_FPCWA

@AlixVezina I did set the default value to "No" when I created the field, but that didn't see to be honoured when creating features until after I updated the feature templates as well (which added the missing fields with the default "No" option). 

IngridHogle

In our use case, we'd like to autofill field B based on field A (when field C is filled in). 99% of the time field B should be the same as field A. We'd love to allow the user to override the calculation of field B in the 1% of instances where field B should be different from field A. (All of these are text domain fields, by the way...in case that is useful to know.)