Copying field input between survey instances

[Eric1]

Hello!

I have a survey that is currently structured like so:

Site Information
    Plot Information repeat
        Species Information repeat

My field crew has asked if it would be possible to flatten the form out so it looks like:

Site information
Plot Information
    Species Information repeat

This way they can complete the form "per plot" rather than "per site" which is often a multi-day project. The caveat is they would prefer not to have to enter all the Site Information multiple times with each new instance. Is there a way to have the last entered field inputs carry over between surveys? Most of the documentation I was able to find talks about auto-populating within surveys.

I saw on another thread that there is an option to copy out of the inbox but I don't want the entire survey copied, just the site information. Perhaps there's way way to add this functionality that way?

[Neal_t_k]

@Eric1 The way you have it set up currently is, in my opinion, optimal.  And your issues could probably be handled by some training and user practices.  

A couple things to define here first:  Inbox is previous entries stored in the feature service,  Sentbox is forms that have been submitted from that local device.  Both Inbox and the Sentbox have capibility to "Edit" and "Copy to a new survey".  Edit is editing an existing record i.e. no new line in your Site Information table but ability to add additional plots, whereas Copy would have a new entry in the Site Information table, possibly ending up with duplicate site.  It sounds like you want to have "copy to a new survey"  turned off or be sure your users know what that means before using it.

However, Editing an existing survey to add a new plot to a site, sounds like your intended use case.  So training users to use the inbox/sentbox to continue work for subsequent plot collections instead of always collecting a new(duplicate) site, to add additional plots would keep your data more manageable.  I would push to get them to get to a place where they can submit data at the end of the day, and then reopen the form from the sent/inbox to add additional plots the next day/visit and resubmit.

A caveat though is that an entry can only be in the sentbox or the inbox, meaning if you submitted a form, and a record of that form exists in the sentbox, you won't be able to find it in the inbox on the device it was submitted from until it is deleted from the sentbox.  It prevents duplicate copies in the sentbox. That said after that they work the same.

There is some other options you could try but if you could get your users to properly use the inbox and repeats, that would be good for your data.

[AlfredBaldenweck · Accepted solution]

Hard agree on your current structure. Can they not just save it as a draft and re-open it the next day until they're done?

Alternatively you could look at a Field Maps combo where you use URL Parameters to pass in the site attribute to the plot survey. 

Assuming you don't already have geometry for the site, I'd do it something like this:

Survey1:

Site Information
    Plot Information repeat
        Species Information repeat

Survey 2 (Pass in URL parameter from Field Maps):

Plot Information repeat
    Species Information repeat

Crucial to point out this would be a separate, duplicate survey, but pointing to the same feature service.

[Eric1]

Thanks very much for the informative replies @Neal_t_k and @AlfredBaldenweck; good to know I have this set up the right way! What your saying makes complete sense. I think they were mostly worried about losing a survey, which for the former case would mean a lot more lost data the the latter. I think you're right that saving into Drafts will do a lot to ease their concerns. Much appreciated!

[AlfredBaldenweck]

Good!

One thing to note though since this bit me pretty hard is that there are a few nasty bugs involving repeats, drafts, and the relevance column. For example, I had a case that where only data from the first page of a multi-page survey will be successfully submitted. I was able to narrow it down to it happening consistently when I would open the survey, do one record in the repeat, and save to drafts. I was able to get around it by moving relevance to the body::esri:visible column.  So, I'd investigate that and make sure.

[Neal_t_k]

To add, I recommend reading this blog post, especially the "Repeats in Inbox" section. You can control  some aspects of what gets pulled in and what is editable using the "bind::esri:parameters" column.

Survey123 Tricks of the Trade: Repeats - Esri Community