Field Maps Arcade Expression - Why does calculated Arcade expressions only return read only variables?

Anonymous User

Hello, I am new to field maps but have came across an issue that I am wondering if anyone else is having or would be a good feature request. I have two layers.. one is a master copy and one is an inspection layer. I am trying to pull information from the master file to populate my inspection (i.e. AssetID, AssetType). In some case, it is possible the AssetType is wrong, so I would like to be able to edit this feature. However the arcade expression only returns a "read only" field. My calculated expression is below by the way. If it does not paste correctly, I got it from this document. Its expression number 7 "Store information from a nearby feature" https://www.esri.com/arcgis-blog/products/field-maps/field-mobility/common-calculated-expressions-for-arcgis-field-maps/

I know that I can just edit the master file to reflect this change and pull the correct information, but I think this could be verified in real time in the field if the returned AssetType was not a read-only attribute. Instead there is an extra step of having to manually edit the data. Wondering if anyone else has had this issue?

 

 

// If feature doesn't have geometry return null
if (IsEmpty(Geometry($feature))) { return null }

// Get the parcels layer
var parcels = FeatureSetByName($map, 'Parcels')

// Buffer the current location and intersect with parcels
var bufferedLocation = Buffer($feature, 100, 'feet')
var candidateParcels = Intersects(parcels, bufferedLocation)

// Calculate the distance between the parcel and the current location
// Store the feature and distance as a dictionary and push it into an array
var featuresWithDistances = []
for (var f in candidateParcels) {
Push(featuresWithDistances,
{
'distance': Distance($feature, f, 'feet'),
'feature': f
}
)
}

// Sort the candidate parcels by distance using a custom function
function sortByDistance(a, b) {
return a['distance'] - b['distance']
}
var sorted = Sort(featuresWithDistances, sortByDistance)

// Get the closest feature
var closestFeatureWithDistance = First(sorted)

// If there was no feature, return null
if (IsEmpty(closestFeatureWithDistance)) { return null }

// Return the address
return `${closestFeatureWithDistance['feature']['ADDNUM']}

JustinReynolds

The reason a field is read-only on a field that has a calculation is because of how and when the calculation is triggered.  Any change to any field will fire all calculations in the form (ALL of them).  As you complete your form all constraints and field calculations are fired for every little change that is made.  So if the field were editable, but also allowed to calculate, then it would just overwrite whatever you typed in once you moved to the next field or collapsed a group and so on.  Then you would fix it and it would again overwrite it in a vicious circle. 

There is also an order of operations when these events fire.  I'm not sure if they are officially documented anywhere, but based on my experience the following appears to happen:

• In general, the form re-calcs all expressions (constraint and field calcs) in form order from top to bottom
• Group constraints appear to fire first before any field expressions... not 100% on this one.
• Field constraints expressions fire before a field calc so that it can check if the field calc even needs to occur

 

So calculated field being read-only is by design and is quite useful.  There are two ways that I handle a scenario where I need to calculate a value and allow the user to change that value. Both involve setting up an editability expression (see the constraint arcade profile) (Note: as of 09/2022 the ability to do this via the Fields Maps UI does not yet exist and thus must be done on the maps JSON via something like AGO Assistant or the ArcGIS Python API).

The first way is to tie the editability expression to a switch which then enables or disables the editability of my field that has a calculation based on the value of the switch (Yes/No, True/False, 1/0, etc.).  Toggling editability on the helper field has the effect of enabling or disabling the calculation on my field of interest which then allows the user to choose when to calculate or when to allow free reign.

The second way is to tie the editability expression to the calculated field itself.  In other words if my calculated value results in any value other than null or a particular value that you have in mind then my editability expression will return "True" and thus disable the calculation and allow me to edit the value of the field that was previously calculated.  

In both cases the editability expression is a property of the field that is being calculated.  The expression returns true or false (as all constraints must) based on any logic that uses any field(s) or geometry or data source you wish to use that happen to be accessible to the feature within the bounds of the constraint profile.

Below the service date is tied to a switch (case 1) and the service number field is tied to itself (case 2). Both are calculated fields and not editable by default.  For case 1, the switch toggling from yes or no determines a true or false return in my editability expression.  In case 2, my editability expression determines if the current field is null, if so it returns false, if not it returns true and along with it enables or disables the field calculation... unless I null the field again as I do below... then the process is retriggered..  This means both of the fields are dynamically calculated and editable and will never be submitted as null. I refer to these cases as dynamic default values when I need them to calc on insert but be editable there after.

 

Calculated Default Values Example