bind::esri:fieldType = null with Inbox record

Question

I am not sure if this is intended behaviour or if this is a bug but.....

Setting a field's bind::esri:fieldType to null (The field isn't persisted in the database. This works great)

Entering a calculation for that same field - let's say something like concat('test'). This should fire regardless of whether this record is a newly captured record or a record retrieved from the survey's inbox. (right ???)

In this scenario when a record is retrieved from the survey's Inbox then the calculation never fires for this field unless you click on the "recalculate" icon:

In my opinion the non-persisted fields should always be recalculated automatically when a record is opened from the Inbox since they dont currently have a value in the database... I might be mistaken but I think in past versions of Survey123 this was how it used to work?

Anonymous User · Answer

Hi @jtmouw1,

There is no update in recent release for null fields and re-running calculations when opening a form from the Inbox. They still need to be manually updated by the user using the recalculation button.

Regards,

Phil.

jtmouw1 · Answer

Any update on this? My use case is wanting to have a datetime update with now() every time a survey is edited, but opening in the inbox does not have that calculation fire.

Anonymous User · Answer

Hi Deon,

What you are seeing when using the Inbox and "null" field types is the expected behaviour.

Currently the "null" value that has been stored in FS when the original survey record was created is treated as being the original value (user entered), so when the survey record is loaded from Inbox it does not get automatically calculated and overwritten. The calculation needs to be manually recalculated (using the calc button) similar to other questions that may have an actual value.

We do have an internal enhancement issue to consider changing this for "null" field types and Inbox, to make them always calculate. Currently no other customer has reported this as being an issue. If you think this is important and want to see this enhancement implemented, could I ask you raise it with Esri Support so it can logged and attached to the internal issue, which will help us with prioritising and gathering more information about such an enhancement, and allow other customers to attach requests to it also.

Regards,

Phil.