Inbox data retrieval fails for some nested repeats, but not all

CarlBeyerhelm1

My survey has a somewhat complicated data model, as illustrated below. Each of the 9 nested repeat elements are made relevant by choices made in the the repeat's parent.

When I open a survey from the Inbox, all of the nested repeat data are present, except for the OBS_POINT, OBS_LINE, and OBS_POLY layers.

Each of the repeats includes a value of "query" in the begin repeat question's bind::esri:parameters parameter.

The OBS_POINT, OBS_LINE, and OBS_POLY data do appear in the corresponding hosted feature layers, so I know that data capture and sync have been successful, but Inbox data retrieval for the OBS_POINT, OBS_LINE, and OBS_POLY layers was not.

The survey's XLSX is attached.  Any insights would be appreciated.  Thank you.

Data retrieval via the INBOX was successful for yellow-tinted elements, and failed for the blue-tinted elements.

WAMo3 20230119.xlsx

89E359CF-8A37-4954-A066-366D71ACCB74.JPG

CarlBeyerhelm1

Yeah, I looked around quite a bit, but couldn't seem to find much guidance on best practices, or issues, in double repeats.  In my case, the OBSERVATIONS table is parent to the OBS_POINT, OBS_LINE, and OBS_POLY repeats, as well as the INDIVIDUALS repeats, so it is a bit convoluted.

Anyway, I incrementally tested each parameter in the OBSERVATIONS repeat, and discovered that OBS_POINT, OBS_LINE, and OBS_POLY data can successfully be retrieved to the Inbox if I remove the value of 1 from their repeat_count parameter. I had wanted only one spatial feature to be recorded for each observation. The cause-and-effect between a repeat_count limitation and failure to retrieve Inbox data is a mystery to me…as are many things. HA!

By removing the repeat_count limitation, however, I had to add a constraint parameter like count(${OBS_POINT})=1 or NULL to avoid exceeding 1 feature per observation. It does the trick, but you actually have to create/accept the second feature before the constraint kicks in, at which point you have to delete the second feature...which is kind of clunky.  So, I'll put this fix in the category of a work-around, but not a clean solution.

Thanks for weighing in.