Edit all Related Repeat Records Calculation

[OliverSandoval_p]

Hello everyone and @JamesTedrick !

I wanted to ask if this functionality is possible. So we have an initial parent table with demographics and related points that are created for every unique event.

Surveys are opened from the inbox where users can add a repeat to the parent demographics record, but they can also edit demographics if need be. 

I want to be able to update the demographics of all the related points after each new repeat so that in post-ArcGIS processing, end users will not have to join two tables based of a ParentID field in order to get demographics. 

Initially I had hidden fields that calculate demographics into the child points records each new repeat, but this can create issues for end users, as the demographics can change, so points that are children of the same parent can have different demographics. 

I guess something similar to batch attribute rules functionality, except the calculation would be stored in the survey and be executed each time a new repeat is added and the demographics change. 

Thank you for any input!

[Anonymous User]

Hi @OliverSandoval_p ,

We are currently working on introducing a new calculationMode parameter and other calculation and indexed-repeat improvements, which may enable you to be able to achieve what you have described.

It sounds like what you want  to do is "always" run calculation, so that when values change or are updated, and new repeats are added, the value in the repeats always changes to match the parent. Does that sound correct?

Please refer to: Expression engine improvements and calculation modes - ArcGIS Survey123 (esri.com)

Regards,

Phil.

[OliverSandoval_p]

Hi Phil,

That feature is exactly what I was looking for! Yes I would like the values in the repeats to always change to match the parent when values in the parent are changed or when new repeats are added.
So the hidden demographic fields in the repeats will have calculationMode = always. Excited for when this comes out, I'll look into testing it, Thank you Phil!

Best,

Oliver

[OliverSandoval_p]

Hi @Anonymous User ,

I've recently been trying to implement calculationMode=auto for the same survey we discussed in this post, but it is not working. Past repeats are not editable but are visible to users, I thought that this maybe the issue. So I put allowUpdats=true in the esribindparameters column in addition to calcMode,. but this had no effect. The calculation is only running on new repeats, not on all related repeats. Any idea why it might not be working?

 Thank you for your time!

Sincerely,

Oliver

[Anonymous User]

Hi @OliverSandoval_p,

If you want to edit previous repeats that were already submitted and retrieved from Inbox, then you must use "query allowUpdates=true" parameters to enable editing of existing data in repeats. If you are just wanting to edit repeats in the same new survey, before submission, a new collect, you do not need these parameters, they only apply for opening from Inbox and Sent box for editing.

The "calculationMode=auto" is the default, so this is the same behavior as previously releases whether it is specified or not. Only the "manual" or "always" parameter are different to the default. In your case it sounds like you want to use "always"? As in your always want it to update if any value or anything in the survey changes?

Regards,

Phil.

[OliverSandoval_p]

Hi @Anonymous User , 

After testing, it looks like calculationMode doesn't work with the current form setup. Even after setting the repeat to allowUpdates=true, the desired fields within the repeat to be always calculated don't update. It seems it might have something to do with the issue this person is having CalculationMode inside nested repeat - Esri Community  The fields I need to be always calculated are hidden, so if an always calculation cant run on a existing repeat field unless its viewed, then I cannot use the feature. 
I think I need to update all repeats with the answer from the most recent repeat instead, but I'm not sure if that's possible either.

Best,

Oliver