Survey123 URL parameters for adding only new repeats in edit mode

[JoshGroeneveld]

I have a survey that users are accessing through embedding the form in a dashboard using URL parameters so that users only see the entries assigned to their jurisdiction.  The form captures current capacity info at various facilities, including facility bed capacity, beds available and beds in use.  We also need the form to track new admissions and new discharges each time the user submits a report for a given facility.

I have been trying to setup the form to capture the daily data updates using repeats so that a related table shows changes over time for each facility.

Is there a way to configure a URL parameter to open a survey in edit mode and only allow the user to submit a new repeat, without seeing any of the previous repeats?  I've followed this post regarding the use of repeats and found the section on setting the bind::esri:parameters to allowUpdates=false and allowAdds=true.  Does that functionality only work in the field app and not the web form?

Ideally, I want the user to see the embedded survey with a repeat section that looks similar to this:

So far, I've only been able to set up the repeat to display this way for a new form submission and not editing an existing one by setting the appearance for the begin repeat to minimal.

It's not a requirement to capture the daily change data in a repeat, so I am open to a better way to do this.  My end goal is to capture the daily data updates so that we can have a record of change over time at each facility.

[IsmaelChivite · Accepted solution]

Hi. The bind::esri:parameters to allowUpdates=false applies only to the Survey123 field app. This parameter is used to control if records in a repeat loaded from the Inbox are editable.  Editing of repeat records from the Survey123 web app is not supported.

For your workflow, a couple of ideas:

1- If you create a survey on top of your related table (you can use the FormID and submission_url columns in the XLSForm settings worksheet to have a survey work against a specific table or layer in your feature service) you should be able to add new records from the web app into the related table.

2- You could also use the Survey123 Power Automate or Integromat Connectors to log changes in your data every time your form is used to make an edit. These changes could be logged into a spreadsheet in Microsoft Office 365 or Google Sheets for example.  If you take this approach, you would not need a repeat.

[JoshGroeneveld]

Thanks, Ismael!  I was able to use the first option you recommended and create a survey on top of the related table.

In case it's useful to anyone trying to solve a similar problem, here's what I did to update the existing form to capture the new daily data updates.

1. Back up the existing hosted feature layer with results so far from the survey.
2. Go to the AGOL content item page of the editable hosted feature layer populated by the survey (not the hosted feature layer views).  On the Data tab add in the new fields that will be included in the related table to capture the daily updates.
3. The original hosted feature layer doesn't contain a related table, so it will delete the existing layer and recreate a new one.  Publish the survey from Survey123 Connect.
4. Using these steps, create a new survey from the existing feature service that points to only the related table.
5. In the survey pointing to the related table, add a hidden question for "parentglobalid" and set the bind::esri:fieldType to esriFieldtypeGUID 

   This is important so that the new records in the related table are tied to the records from the parent table.  Here's the feature service page showing the fields in this related table: 

   
6. There were only three questions in the survey for the related table I wanted users to fill out.  The rest of the fields are calculated based on those values.  I placed all of these calculation questions into a group, and set the group appearance to hidden.
7. Users are submitting updates through a dashboard where selecting a feature in a list element filters a survey in an embedded content element.  Since the feature service populated by the survey was recreated above, I had to recreate the list element in the dashboard to point to the new feature service.  My dashboard now contents two embedded content elements.  The first one points to the original survey with basic facility information, with URL parameters set to open the form in edit mode and hiding all of the questions in the repeat.  The second embedded content element points to the survey on top of the related table, but it is not in edit mode so that the users submit a new related record.  The URL parameters for this second embedded content element capture the globalid from the main feature service and set that equal to the parentglobalid in the related table: 
8. Ensure the actions set on the list element filter both embedded content elements.
9. The dashboard had some URL parameters of its own so that users would only see the data for their jurisdiction, so I had to recreate the URL parameters because the feature service feeding the list element was updated.

In the end, the final dashboard users see to submit their updates looks like this:

[PaulMillhouser]

Your suggestion to create a survey atop the repeat table seems like it would help me in a similar case, but I have run into a roadblock. I've created a survey to allow multiple reviewers to evaluate the same proposed project, and so I have the review portion of the survey as a repeat. Using an XLSForm, I've created the survey and feature layer, and populated the feature layer with details of projects. The reviewers will use a separate review-only survey pointed at the same feature layer. Reviewers will access the survey via a dashboard where the survey is embedded. I have this working well, but I do not want project reviewers to see the responses of previous reviewers, both to avoid their having to scroll through prior responses and to avoid prejudicing their reviews.

To address this issue, I've followed your suggestion of having the review-only survey address the repeat table directly using the submission URL and FormID. When I attempt to publish the survey from Survey123 Connect I receive the following error message:  "The custom feature service submission_url is not compatible with this survey. Parent layer id 0 not found for table criteriabeg." That is indeed the correct name for the table, and the parent feature layer is indeed shown to be 0 on its information page. The feature layer and the table are related via GlobalID and ParentGlobalID fields. Do you have any insights as to what is happening?