Allow Editing on Fields with Arcade Calculated Expressions

[JoshuaFlickinger]

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.

[LindsayRaabe_FPCWA]

I agree that sometimes it would be useful to be able to edit a pre-calculated value. In our use cases it would be that the field returns the users Name or ID, but sometimes they might be filling it out on behalf of someone else and would need to change the name to someone elses. 

@JoshuaFlickinger in your current situation where the accuracy isn't good enough to make the intersection - have you considered adding a buffer to the intersection? It would act like adding a search distance. You can also add an IIF statement to return "Unknown" instead of the first random value if it fails to find a search. The buffer would be useful if there's enough space between plots to ensure that you can still find the one you need within a reasonable tolerance. I've listed a code I use below for you to review. 

var BufferedFeature = Buffer($feature, 20, 'meters') //Adds 20 metre buffer to the feature geometry before intersecting
var intersectLayer1 = Intersects(FeatureSetByName($map, 'FPC Plantations'),BufferedFeature) //Searches this layer 1st. 
var intersectLayer2 = Intersects(FeatureSetByName($map, 'Planned Establishment Areas'),BufferedFeature) //If no value found above, searches this layer

//Search of Layer 1 - returns value in field "Name" - if empty, then runs search on Layer 2
for(var f in intersectLayer1) {
    if(!IsEmpty(f.Name)) {
        return f.name
    }
}
//Search of Layer 2 - returns value in field "Name" - if empty, then returns "Unknown"
for(var f in intersectLayer2) {
    if(!IsEmpty(f.Name)) {
        return f.Name
    }
}
return "Unknown"

[lah]

This is absolutely needed. 90% of the time the calculated value may be the correct one, but there is always an exception that we need to account for. My team has been unable to take advantage of this functionality because there is not a single use case where we would want to force a value on someone.

May be a duplicate of this idea: Calculated Default Values 

[MappyIan]

Being able to edit calculated fields is the very first problem we hit when trying to implement Field Maps.  As others have said, calculated fields are correct for about 90% of the time, but sometimes you need to be able to edit the calculated value.  I really don't see why a field can't be calculated, and then editable if the value is not correct.

It would be awesome if this could be implemented.

[cbp-geus]

We experienced a similar issue with our field season using a field expression in our ArcGIS Field Maps app. Our geologists wanted the locality number to be filled out in a sequence automatically based on the first locality they make, so they don't have to remember each new locality number. In total they usually collect over 2700 localities in a field season.

We use a simple field expression from two fields to get a sequential locality number and a unique locality name, but we discovered that when our field geologists edit their collected localities, e.g., adds a new photo attachment or update their field notes, the sequence number is also updated in the geodatabase, which is very unfortunate. We are debugging our code now to see how we can prevent that, but our field geologists want to be able to also edit/correct the calculated field value them self if needed.

//Create a sequential locality number
var previousRecord = FeatureSetByName($map, "Locality", ['LocalityNo'], false);
var lastRecord = First(Orderby(previousRecord,'LocalityNo DESC'))
if (Count(previousRecord) == 0) {
    return "1"
} else {
    return lastRecord.LocalityNo + 1
}

//Create a unique concatenate locality name with locality number
var createuser = split(GetUser($layer).username,'_')
var createyear = Year(Now())
var locid = $feature["LocalityNo"]
Concatenate(createyear,createuser[0],locid)

[HollyTorpey_LSA]

We really need this functionality, too. There have been so many times when I wanted to add field calculations to make data collection fast and easy 95% of the time but can't because of the 5% of cases when field crews would need to edit the value.

[gis_user_ca]

This would also be helpful for my workflow where we use Arcade to fill in the nearest feature but sometimes it pull the wrong feature value if there are many features close to the collection point. The user would need to be able to correct the parent value. Bonus point if related records from the corrected feature reautopopulated/corrected the related feature values. 

[GrantDix]

This functionality would be very valuable in our workflows. I want to make forms that are easier for users to use: that prepopulate data when appropriate, but also allow the user to change that value manually if they want/need to. A specific example would be with tree inspections. Lets say last year they identified a bug problem. I want to pull the note from last year's inspection about the bugs into the new inspection, this way the user doesn't need to repopulate that. It even then lets them know that bugs were identified previously as a problem. If the bugs are still there, the user can just save the new inspection with the note. If the bugs are gone, they can remove/change the note and then save the record. This level of functionality, being able to edit/override a value from a calculated expression, would be a major benefit to my organization and workflows.

[PamelaKing]

This capability would be hugely helpful for us too--for another related reason. 

This past summer we had a big issue when we used the calculation "GetUser($layer).fullName" not realizing that this calculation doesn't work if the device is offline (a known limitation that we didn't know about).  Unfortunately, using a calculation makes the field un-editable and required. So when our users were collecting data and in a completely offline area, they were unable to complete/submit the form/data because the field was required and the calculation didn't work...and since it wasn't editable there was nothing they could do about it to move forward. 

It seems like a small thing to have the users name calculated, but it helps with consistency and is convenient. Making the calculated fields editable would fix these grid lock situations when users are offline, while allowing for the convince when they do have service.   

[LindsayRaabe_FPCWA]

@PamelaKing interesting - we use the exact same expression for the same reason in offline enabled maps and it works fine both online and offline. For us, it would be useful for staff to be able to override it when they are updating a feature that is not their primary responsibility but for which they are temporarily looking after while someone else is on leave. 

[PamelaKing]

@LindsayRaabe_FPCWA that is really interesting. I wonder if you have some different setting on your device or in your form that let it work--that would be awesome.  Even with it working for you, thanks for sharing that the editing would be helpful.  I agree! 

I am so curious...have you all used the your form/calculation in  areas with no service at all?  That was when we were having issues.  For a while we thought it was just working, but we figured out what was happening was that people were in their offline maps but did have some level of service so the device was able to run calculation. 

I just tried the calculation in a test map and put my device in airplane mode to simulate being completely offline and it failed. If you know of a setting that can make it work, please share with me.