Pulldata calculation not honoring calculation mode?

[TonyaLong]

I have a field in my survey (Local_Zones) that is a select one question, and I recently created a polygon layer that displays some, but not all, of the zones. The zones are set up by the surveyors, so if they provided me with GPS boundaries, then their zones were added to the layer. I've now added a simple pulldata calculation to auto fill the zone based on the surveyor's GPS location (a sample of my survey is attached).

This works great for the folks whose zones are shown on the map. For everyone else who manually selects their zone, the field is getting cleared out every time they edit or view a record from the inbox, presumably because their location is not within a zone on the map. The only thing I've found to prevent this from happening is to set the calculation mode to manual, but that defeats the purpose of setting it up to auto fill in the first place. These are the other things I've tried.

• Setting the calculation mode to auto or whenEmpty.
• Updating my version of Survey123 Connect, just in case (I'm running 3.22.49).
• Using various If statements with different attributes to try to limit when the pulldata calculation applies, including using a hidden field for pulldata("@property", 'mode') to limit the calculation to new surveys.

None of these worked and ultimately, the If statements aren't helpful because the underlying issue seems to be that the calculation is running when it shouldn't be, which clears out the previous answer. I only want the calculation to run when the user is filling out a new survey - then the answer needs to be preserved when editing or viewing. Based on this info, even if auto wasn't the correct calculation mode, I would have at least thought that whenEmpty would do the trick, so I'm not sure why it seems to always recalculate unless it's set to manual. 

If anyone has any ideas, I'm all ears. @IsmaelChivite, am I missing something with how the calculation mode works or is this the expected behavior? Thanks in advance!

[Neal_t_k]

Not sure how this would work with the rest of your form, but you could try putting that section in a repeat and setting the bind::esri:parameters to "query allowUpdates=false"   I believe this would allow viewing of previous entries through the inbox but not allow updates.  A new repeat would have to be added for the calculation to trigger and you could put a constraint on the repeat to only allow one?  

[TonyaLong]

I thought about that too, but we already have two other repeats in our survey and working with those related tables on the back end is tricky enough for our stakeholders. I'm hesitant to introduce a third related table for them to deal with for just one field.

[TylerGraham2]

I wonder if there is a conflict between the calculation and choice_filter on that field. I would try deleting the choice_filter and seeing what behavior you get with the different calculation modes. If that solves it you might look at setting up a calculate question with the esri:fieldType set to null, so it doesn't create a new field in the feature service and try passing the calculate question to the Local_Zones question as a default value or the calculate column.  

[TonyaLong]

Thanks for the suggestions! I removed the choice filter and it didn't have any effect, so I went ahead and added it back in. There are a couple hundred options without that filter, so it's definitely necessary. Unfortunately, putting the calculation in a null field and using that value in the calculate column didn't work either - it gave me the same behavior as just having the pulldata function in the calculate column of the original field. Even when it's in another field, that pulldata calculation seems to be overriding the calculation mode. I was hopeful that the value from the null field might work as the default and then realized that the default column doesn't accept expressions, so you can't pass values from another field. That only works in the calculate column, which brings me back to the original issue. 😕

[Neal_t_k]

Have you tried playing around with the settings/parameters on the geopoint question?  The calculation on your local_zone field is dependent on your geopoint question, So when that changes it triggers the calculation. You could try the "press-to-locate" appearance. Initially user would have to interact, but it might not recalculate automatically upon review unless they interacted again?   I would think the geopoint stays the same when editing, but you do have some extra parameters on that field.  This was an interesting entry possibly regarding your issue:

https://community.esri.com/t5/arcgis-survey123-questions/survey123-location-capture-when-editing/td-...

[TonyaLong]

Even though the geopoint doesn't recalculate when editing (unless the user does it manually), I did try setting the calculation mode to whenEmpty. Since our field type is PointZ, I also tried setting our elevation field calculation mode to whenEmpty just to see if that would make a difference, but neither of those things helped. We used to have the press-to-locate appearance, but our users specifically asked for the GPS location to fill in automatically, so I don't want to take away that functionality. 

It's so odd because I can't find anything that should be triggering that calculation to run, and yet it does every time unless the calculation mode is set to manual. None of my other calculations have that problem, so it seems like it must be something associated with the pulldata function, but I can't figure out what.

[MohandK]

there are real issue with pulldata, that's refreshed only once at survey application start !!

i confirme that pulldata calculation not honor calculation mode,  @IsmaelChivite can you confirme that ?