Repeat questions in 'Inbox' not showing

[DanielKonzek]

I enabled 'Inbox' for a survey with repeat questions.  I added the field 'bind::esri:parameters' to my survey and set the value to allowUpdates=true query=’1=1’ in this column for my "begin repeat".  I am able to view and edit my repeat questions from my "Sent box", but they do not show up  when I access a survey from my 'Inbox'.  Any suggestions?

Thank you,

Dan

[erica_poisson]

All of the testers, myself included, have re-downloaded the survey to see if that helps with the issue, but it made no difference. I just tried again this morning, and see the same hang-up on the nested repeat table (Related_Table_Photo_Information) via the "sending" dialog. When I originally tested this survey after building it, it was not shared, and it worked fine. After initially sharing with my testing group, one person was able to successfully complete the workflow and submit the survey - this was around February 1-4. Since then, no sharing to either the form/feature layer has been changed. 

I am curious if it is the workflow causing the issue, although it did work initially. It goes as follows - begin the survey on a PC and complete 'pre-field' portions; submit. When in the field, go into the Inbox, fetch the proper survey and complete. Portions completed in the field include questions in the 'main' table, a few repeat tables, and the nested repeat portion which consists of the following: a repeat that can have multiple geopoints, and within this, a nested repeat table where with attachments, that can be submitted multiple times per geopoint. Here is my schema:

All users are able to submit the 'pre-field' portion of the survey. When attempting to submit after accessing the survey from the Inbox, the survey hangs when submitting. All devices see the same error - I've personally tested on Windows PC, iPhone, and MacBook. My users have tested with iPads. I've attached a log file from this morning.

[Anonymous User]

Hi Erica,

Ok, I think we are getting closer to the root cause of the issue, however still not there yet. So you only get the error when trying to edit a record and re-submit, not when submitting new records? This is likely related to the multiple_geopoints layer or photo_information table. There could be an issue with the layer order and processing of submitting editing data to the correct layers/tables.

Can you send me a copy of your xlsx file also so i can take a look to try and work out what is happening in more detail and the configuration of your layers/tables?

Thanks,

Phil.

[erica_poisson]

Hi Phil,

Yes - the error (or lack thereof) only occurs when editing a record and re-submitting. Just for some additional clarification, when users are completing the 'pre-field' portion of the survey, they are not completing at information in the "multiple geopoints" feature layer, or the "related table photo information" table. It isn't until the 'in-field' portion that the tables I just mentioned are completed. During this time, the main feature layer and some of the other related tables will also be added to.

I've attached a copy of the XLS form here.

Thank you so much for your help with this! 

Erica

[Anonymous User]

Thanks Erica,

Are you editing the surveys via the Inbox or via the Sent folder and selecting edit sent survey?

I have been able to reproduce the error and now investigating it further. It appears to only happen on editing the record but only when adding new attachments and relates to the attachment table which is nested.

If you submit a new parent record (new submit) with all related tables, layer and attachments on the original submit, it works as expected and all data exists in feature service including the attachments which get sent.

I think the issue is that the attachment table is nested inside another repeat, and the edit data request is failing to send attachments to that table.

Phil.

[erica_poisson]

Hi Phil,

We are editing via the Inbox.

It's good to know the error is re-produceable, however I am curious why I was able to successfully edit a survey via the Inbox, and submit (with attachments to the nested repeat) when initially testing this survey around February 1; I also had a test user who was able to successfully do this around the same time.

I was thinking that maybe it was my bind parameter for the "multiple geopoint" and the "related table photo information" repeats that was causing the issue. I had it set so these could be editing via the Inbox. I removed the parameters, republished the survey and did another test, but saw the same result.

Erica

[Anonymous User]

Hi Erica,

Thanks for the extra information above. After troubleshooting your survey further, I found the cause of the crash. It turns out if you are using repeat count on a begin repeat question and the Inbox is enabled, and then you use the "allowUpdates=true" parameter applied in the bind::esri:parameters column, the app will hang on submission when editing a record. This is a new bug previously not identified and likely introduced in 3.2 due to some improvements made to repeat count in other areas.

I have logged this in our system, and will try to get an update to the beta app on EAC as soon as we can so you can test it out. In the meantime the only workaround is to remove the "allowUpdates=true" parameter from all of your begin repeat questions using repeat count, and then you will be able to edit surveys from the Inbox or Sent box. However you will only be able to edit questions that are in the parent layer or in a repeat that is not using repeat count. You can still use the "allowUpdates=true" parameter on repeats that do not have repeat count applied. I think this will work for your workflow described above, as the repeats at the end of the survey they are editing in the field do not use repeat count, only the first lot do that are edited in the office.

Regards,

Phil.

[erica_poisson]

Hi Phil,

Thank you! I do have an additional question - if it is more important to me that end users can see the repeat information in the field, could I remove the repeat counts on the repeats towards the beginning of my survey and leave the "query" parameter within the bind::esri:parameters for those 4 repeats? That way end users can see the information they entered during their "pre-field" work, but not make any changes?

I made the change above, and received the following error message when trying to view the feature layer item details in AGOL - "Unable to load https://services1.arcgis.com...=json status: 500". I saved a copy of my XLS, deleted the survey and recreated it. I tested my workflow - complete the "pre-field" portions of the survey on my desktop, submit it, and then open the survey on my iPhone, retrieve the partially completed survey from the Inbox, complete and submit. Now, there are no errors when submitting the survey, however I still get the "Unable to load https://services1.arcgis.com...=json status: 500" when trying to view the feature layer item details in ArcGIS Online. I also can't load the data in the Survey123 website. I checked the ArcGIS Online Health Dashboard, and there are no issues shown. I went back into the Survey123 app on my PC, refreshed the Inbox and can see the completed survey there - including all of the information within the "multiple waypoints" and "related table photo information" sections. This seems good, but I'm perplexed by this new issue.

Again, thank you for the continued help with this!

Erica 

UPDATE:

It looks like there were intermittent issues with Hosted Feature Services this morning, which were the root cause of issues on my end. I just tested viewing my data via the Survey123 website, and via the Item Details page of the feature service, and it seemed to be working without issue. I was also able to export to both of my report templates from the Survey123 website.

I really appreciate your continued help with this, I don't think I would have figured out that repeat counts/the bind::esri:parameters were causing issues without your assistance.

[Anonymous User]

Hi Erica,

Glad it is all working now, and happy to help and assist where I can. Yes, i think there was some interruption to AGO and Survey123 website last night, but appears to be fixed now. 

Phil.

[Anonymous User]

Hi Erica,

We have just updated new 3.4 beta builds to EAC which address the Inbox issues you were having above with "allowUpdates=true" parameter on begin repeat questions using repeat count. Can you please test your surveys again with latest builds and using the original configuration.

You can find the latest 3.4 beta builds here: Survey123 Early Adopter Community

Regards,

Phil.

[OussamaMerhi]

It works well and no errors when you submit.

Sent from my iPhone