idea Calculated Default Values in ArcGIS Field Maps Ideas

Calculated Default Values

JustinReynolds — Wed, 27 Apr 2022 14:02:16 GMT

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

Re: Calculated Default Values

lah — Wed, 27 Apr 2022 14:17:18 GMT

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!

Re: Calculated Default Values

JustinReynolds — Wed, 27 Apr 2022 14:51:22 GMT

@lah 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.

Re: Calculated Default Values

lah — Wed, 27 Apr 2022 15:27:43 GMT

@JustinReynolds that does make sense.

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

Appreciate the info!

Re: Calculated Default Values

JustinReynolds — Fri, 29 Apr 2022 16:00:09 GMT

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:

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).

Re: Calculated Default Values

JustinReynolds — Mon, 02 May 2022 17:52:13 GMT

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" } ...

Re: Calculated Default Values

DebHSF — Wed, 18 May 2022 14:01:31 GMT

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.

Re: Calculated Default Values

JustinReynolds — Wed, 18 May 2022 18:01:36 GMT

@DebHSF

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

Re: Calculated Default Values

DebHSF — Thu, 26 May 2022 14:58:58 GMT

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.

Re: Calculated Default Values

DebHSF — Wed, 12 Oct 2022 16:11:08 GMT

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!

Re: Calculated Default Values

SakariHautala — Tue, 08 Nov 2022 14:41:07 GMT

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.

Re: Calculated Default Values

ChristyFung — Wed, 14 Dec 2022 21:50:51 GMT

I hope this feature would be added to field maps, allowing us to manually edit the calculated values are essential since sometimes the values are not correct,

Re: Calculated Default Values

JohnFannon — Thu, 02 Mar 2023 09:47:12 GMT

A calculated default value that remains editable (if the field is editable) is absolutely a requirement. The field calculations are generally there to speed up and simplify data collection, but should not prevent the user overriding them if required.

Re: Calculated Default Values

JustinReynolds — Fri, 07 Jul 2023 14:20:03 GMT

This has been implemented in AGO and AGE @ 11.1.

Re: Calculated Default Values

LanceKirby2 — Tue, 01 Aug 2023 21:04:45 GMT

@JustinReynolds Could you specify what feature has been implemented in AGE 11.1? Is it just the toggle switch logic you showed in your gif along with edits to the source JSON? Or is there an actual feature to allow for users to overwrite calculated values that I am missing?

Re: Calculated Default Values

JustinReynolds — Tue, 01 Aug 2023 21:28:48 GMT

@LanceKirby2

The ability to natively author editable expressions and Form Calculations in Field Maps Designer are what I am referring to. In my previous post with the GIF, I was implementing this without native support.

You no longer need to make edits to the JSON directly in order to deploy the editable expressions. Editable Expressions are the piece you need in order to allow users to edit (overwrite) calculated values. There isn't a specific feature that will "allow users to overwrite". You will need to setup the logic using Arcade to make it work, but now you have the tools that you need to make it work without having to deal with AGO Assistant.

I just so happened to tie that previous example to a switch, but you don't need the switch to make it work. In other cases I simply calculate the field if it is null | Empty... otherwise if it is already calculated, then the user can edit it. This is the idea around calculated default values... on INSERT the field is null, so it get calculated... but after it is calculated the user can edit the field. This is possible because of the editableExpression.

Hope that helps.

Re: Calculated Default Values

lah — Tue, 01 Aug 2023 21:34:13 GMT

@JustinReynolds I am also not getting this ability in AGE 11.1. Are you working with hosted feature layers?

Re: Calculated Default Values

MarkEastwood — Tue, 01 Aug 2023 21:49:20 GMT

@JustinReynolds

"I just so happened to tie that previous example to a switch, but you don't need the switch to make it work. In other cases I simply calculate the field if it is null | Empty... otherwise if it is already calculated, then the user can edit it. This is the idea around calculated default values... on INSERT the field is null, so it get calculated... but after it is calculated the user can edit the field. This is possible because of the editableExpression."

This is exactly how I would like some of my editable fields to be configured but I don't seem to be allowed to have a calculated expression while also being allowed to edit the field. Could you provide some screenshots of your form configuration?

Re: Calculated Default Values

JustinReynolds — Wed, 02 Aug 2023 13:07:55 GMT

@MarkEastwood Well, ESRI seems bent on making me out a liar. As I went to create an example for you on this something as clearly changed recently; probably with the June release as Forms that were working as expected no longer do. The field calculates (in some cases) and the user can change the value, but if they null the field again it no longer re-calculates.

If I had to guess it has something to do with them deprecated "editable" and replacing it with "editableExpression" or the execution logic. ESRI reads your Form and builds an execution map or tree of sorts so that the Form execution is as efficient as possible.

I works great if my editable logic is based on a different field (e.g. using a switch to toggle editability), but is unstable or flawed if the editable expression is based on itself (e.g. checking for null on itself).

Here is how it worked a month or so ago.

The overall setup... Shown using AGO.

The overall setup

The editableExpression

The form calculation

Re: Calculated Default Values

MarkEastwood — Wed, 02 Aug 2023 14:19:37 GMT

Thanks @JustinReynolds, I really appreciate the time you spend answering these questions.

Very frustrated with ESRI's recent development, nothing ever seems to work as it is advertised.