Calculated Default Values

[JustinReynolds]

We are now implementing form calculations in Field Maps on several projects and these have been a big help... some bugs to work through, but overall pretty good so far.

By design, a form calculation renders the field un-editable from within the form. This leaves me wanting a little bit as I have use cases for a calculation that fires once and only once on insert/creation but allows the field to remain editable. Call this calculated default values. Separate from a database default value of the underlying feature service and those set in feature templates which are both examples of static default values.

The classic use case is a date field (not a system date field like editor tracking)...

On insert set the date to today. e.g. return Today(); or return Now();. However, allow the field to remain editable so that a user can make a change. 90% of the time the user would need Today's date and when this event fires the user can ignore the field, but in the event that they are recording an inspection/event that occurred yesterday, today, then allow the user to manipulate the date.

By design it could be a different category of a form's field capabilities.

Currently we have

• Calculated Expressions
• Conditional Visibility

Can an option be added for these types of cases? Calculated Default Value Expressions?

Thanks

[LarissaH]

We are still on Enterprise 10.8.1 and have not been able to take advantage of the awesome calculated field functionality just yet. 😞 

I did not realize this was not already the case, however. This absolutely would be needed for every one of our team's use cases. I can't think of a time where I would want to calculate a field for the user and lock it, making them unable to change it if needed. Calculations, to me, serve as a convenience to users. As you mentioned - 90% of the time, the value will be what they want it to be, but there are always exceptions where they may need to change the value manually.

Hope to see this implemented soon, ready for my team's next upgrade!

[JustinReynolds]

@LarissaH Yea it was a disappointment to see that the field must not allow editing (from within the form) if it is calculated.  I see why the did it though.  The edit context is set to "UPDATE", so what is happening is that anytime any field in your form is updated all fields with calculations are recalculated... so if a user were to change something it would just overwrite their change with the  recalculation.  There are some options in the Form Calculations Arcade Profile that may help mitigate that, but for now at least, from within the form, the field is enforced as not editable. It is editable outside the form, however, in the table view and it looks to be editable in Field Maps when editing a feature; as the configured form is not displaying when editing a feature (outside of the cached session) or editing multiple features (regardless of the session)... the form not being honored while editing an existing feature might be a bug (Android) or an undocumented limitation right now.

We use ArcGIS Online and ArcGIS Enterprise depending on the nature of the project and the client.  We are about to complete our migration from 10.7.1 to 10.9.1 in about 10 days.  Sadly, based on ESRI's documentation, form field calculations are not supported in Enterprise at all, even as of 10.9.1.  My hunch is that they won't be supported until 11.0.0 or 11.0.1. So it remains an ArcGIS Online only feature probably until the ESRI UC or the end of the year. 

[LarissaH]

@JustinReynolds that does make sense.

and, ahhhhhh - that stings. Us Enterprisers getting left in the dust again 😞 

Appreciate the info!

[JustinReynolds]

I posted this in the early adopters Field Maps forum as well and got a interesting response.  Field Maps mobile technically supports this (though it is a bit of a different idea, the result is the same).

This is not directly supported/exposed yet in Field Maps web authoring, so it is a bit more technical to implement.

Based on the dev's response, I reviewed the relevant constraint profile documentation:

• https://developers.arcgis.com/arcade/guide/profiles/
• https://developers.arcgis.com/javascript/latest/arcade/#forms
• https://developers.arcgis.com/javascript/latest/sample-code/editing-featureform-fieldvisibility/

I'm inferring that I can appropriately modify the web map's json to include this functionality and Field Maps mobile will support it. I should be able to define a new expression in the ExpressionInfos section that evaluates to true or false as suggested (either by checking the value of a helper field or meeting some other condition presented in the form) and then just pass that expression by name to the editableExpression property of a field or set of fields. This is analogous to the visibilityExpression and requiredExpression properties.  I could in theory have a single "user enabled override switch" or form condition that would enable or disable all form calculations at once.

The expression that comes to mind for the date field is to just check if its value is null.  If it is not null, then my editable expression would evaluate to true, rendering the field editable and therefor disabling form calculations on that field since fields will only calculate if the editability is false. My hope is that since it would be null on insert, the field would calculate today's date, then it would no longer be null and thus the edibility would become true.  The field would no longer calculate and would be editable by the user.  This might break down if the field were to become null again.  I plan on testing this out and following up.

This won't be exposed in Field Maps web form authoring (Either in Map Viewer or the Field Maps web app).

[JustinReynolds]

Following up again.

I can confirm that this works great on iOS, but does not work completely on Android.  On Android, the editability is toggled successfully, but the form fails to calculate the date when the field's editability is toggled to false (there is also no "calculating" animation, it just disables the field). I'm seeing similar behavior on some other fields that calculate fine in iOS and the web map (chrome), but won't calculate on Android unless I shift the field up in the order of fields.

Android || Galaxy S10+ || App Version 22.1.2 || Build 1128
iOS|| iPhone 13 Pro || App Version 22.1.0 || 690

Example map json snippet (See line 25):

...
"formElements": [
    {
        "description": "Toggle the switch to manually override the service date",
        "label": "Service Date - Override",
        "type": "field",
        "editable": true,
        "fieldName": "service_date_override",
        "inputType": {
            "type": "switch",
            "offValue": 0,
            "onValue": 1
        }
    },
    {
        "description": "Enter the date the test was performed.",
        "label": "Service Date",
        "type": "field",
        "editable": false,
        "fieldName": "service_date",
        "inputType": {
            "type": "datetime-picker",
            "includeTime": false
        },
        "editableExpression": "constraint/edt/cond/service_date_override",
        "requiredExpression": "constraint/req/cond/is_required",
        "valueExpression": "expr/now"
    }
...
"expressionInfos": [
    {
        "expression": "true",
        "name": "constraint/req/cond/is_required",
        "returnType": "boolean",
        "title": "is_required"
    },
    {
        "expression": "// editability_service_date_override\r\n// if switch is off (0) -> Editability = false => Calc will execute\r\n// if switch is off (1) -> Editability = true => Calc will not execute\r\nif ($feature[\"service_date_override\"] == 0) {\r\n    console('Manual Override is off');\r\n    return false;\r\n} else if ($feature[\"service_date_override\"] == 1){\r\n    console('Manual Override is on');\r\n    return true;\r\n} else {\r\n    console('Manual Override is null or invalid');\r\n    return false;\r\n};",
        "name": "constraint/edt/cond/service_date_override",
        "returnType": "boolean",
        "title": "service_date_override"
    },
    {
        "expression": "return Now();",
        "name": "expr/now",
        "returnType": "date",
        "title": "Now"
    }
...

[DebSF]

Agree that being able to change a calculated field if needed is essential. Our use-case is for dates too. The majority of the time the form will be completed for the current date, but on the occasions it's not the user needs to be able to choose a different date. 

A field being editable or read-only is already controlled via the feature layer's attribute settings, so ideally this would be honoured even when a calculated expression is used.

[JustinReynolds]

@DebSF 

This is supported by Field Maps Mobile (ArcGIS Online) currently.  You just can't author the solution via Field Maps Web App yet.  You would need to do it by modifying the web maps json. I pasted an example above.

To show case what this feels like in the app, review the GIF below.  My Service Date and Service Number fields are both calculated values.  I've tied editability of the Service Date to an override switch and the editability of the Service # field to itself (if it has a value, then it becomes editable... if I null that field it will briefly become un-editable, recalculate, then become editable again.... it happens almost faster than you can see it happen) You can't see it, but I'm hitting the x button on the service # field to null that value, which forces a recalculate... which is partially based on the service date field.

Calculated Default Values Example
  

[DebSF]

Thanks @JustinReynolds. I'm not sure if the json method will be possible for us due to the way the layers are set up (and we're on Android), but will give it a go.

[DebSF]

Hi @JustinReynolds. I'm looking into this again just now and have almost got things to work, but I find when I null a field (tap the X button), the value is not recalculated, it just remains as an editable field. Trying to work out what could be different to your set-up - are the fields you're doing this on set to allow null values or not?

Also I find if I make any changes to the Field Maps form in the AGOL Field Maps web app, even to different fields, the json gets reset and I have to go into ArcGIS Assistant and edit the json again. Do you find this too?

Thanks for figuring all this out by the way!

[SakariHautala]

This feature would definitely be useful. We have a calculated expression for fetching the name of the user. It works fine, but in case of offline use, the field won't populate, and since the field is mandatory, you can't submit the feature. For now we had to remove the calculated expression from the form altogether, but the ability to edit a calculated field would be much better.