Building Multiple Survey using Related Tables for Repeats

[ChrisFerner_YT]

I have been trying to get this to work for weeks. I have done SO much searching for how to do this and gathering of ideas from here and there but nothing has helped get the survey's to actually publish. 

I initially published this as One feature layer and 5 survey's, but I need non-GIS staff to be able to actually look at the data and determined the best way to do that was to have it all related before publishing to AGOL. 

• I have a point feature layer, with 5 related tables. Three of those have repeats which have been built into the GDB in Pro as additional related tables.
• All relationship classes are built with GlobalID & GUIDs
• Two of the tables (EventLog and Species List(which needs an external CSV of species)) do not have relates. I tried to point directly to the child table for these, but I must be using the wrong URL. I get the wrong submission URL no matter what I have tried.
• It doesn't quite make sense to have ALL of the tables in each of my five surveys. Or is that the way I should be doing it and making the point feature and the 4 tables not being used being 'hidden'?

I'm trying to attach my xlsx but it's not working. I'm happy to share the file.

[ChrisFerner_YT]

See images and xls of the feature layer and ALL the tables.

This is for a vegetation survey of a large plot with small quadrat plots along a line that cuts thru the plot. There are lots of species lists as well.

[Neal_t_k]

You can use external CSV for choice lists  Survey123 Tricks of the Trade: External choice lists, but as far as I know the table would have to be related and in the feature service for it to be used for data entry.  All of your forms would not have to include all your tables and like you said remain 'hidden'.

[DougBrowning]

My old write up on this may help.  https://community.esri.com/t5/arcgis-survey123-questions/mapping-with-survey123-within-a-polygon-or-...

We have 15 forms all point to the same service and it works.  For species list I use CSV as it does not change often.  We have 11 actually, one for each state.

[TylerGraham2 · Accepted solution]

• I have a point feature layer, with 5 related tables. Three of those have repeats which have been built into the GDB in Pro as additional related tables.

• All relationship classes are built with GlobalID & GUIDs

What are your relationship types that you created? Survey123 only supports 1:M relationships

• Two of the tables (EventLog and Species List(which needs an external CSV of species)) do not have relates. I tried to point directly to the child table for these, but I must be using the wrong URL. I get the wrong submission URL no matter what I have tried.

This is contradictory, if there is no relationship connection to or from those tables with other tables/layers they can't have a child table or a parent table, because there is no relationship to link them. 

The tables in your feature service that do not have relationships can't be used for data collection as part of a form that uses other feature layers/tables.  This is because without a relationship there is no way for Survey123 to find the path to the table.  However, you can make it its own standalone form by pointing the submission url of a form to that table and only that table.  

To do that, you create a new form using the Feature Service option. That will generate an xlsform and if you go to the settings tab of it you change the form_id to the name of the table and in the submission url add the layer id to the end of the submission url.  Since you mention event logs as a standalone with no relates lets use that as an example.  You would change form_id from Monitoring_Plots to Event_Log and lets say the Event Log has a layer id of 5 (you can find it by going to your hosted feature service in AGOL and looking at the id numbers of all the layers and tables).  Add /5 to the end of the submission url.  What you have done is told Survey123 to look for the Event_Log table that matches Layer ID 5.  If those don't match, like you leave the form_id as Monitoring_Plots but add the Event_Log layer ID to the submission url, it won't work.

• It doesn't quite make sense to have ALL of the tables in each of my five surveys. Or is that the way I should be doing it and making the point feature and the 4 tables not being used being 'hidden'?

Unless you are letting Survey123 Connect create the initial feature service, you don't need to include every question/table/layer in a form.  You can even have multiple forms that only reference parts of a feature service or even only part of a feature layer or table.  If you have an existing feature layer that has questions 1 through 10. Surveyor 1 only needs to interact with question 1, 2, 6, 8, 9, and 10, and Surveyor 2 enters data for questions, 3, 4, 5, and 7.  You create 2 forms that point to that feature layer (using the method I described earlier using form ID and submission url). You only need to have the questions in the xlsform that need to be answered, they don't need to be set to hidden, just delete them from the spreadsheet. So, for the Surveyor 1 form you publish it with just questions, 1, 2, 6, 8, 9, and 10 and Surveyor'2 form gets published with questions 3, 4, 5, and 7.  

The same applies for repeat tables of an already published survey, if the particular form doesn't require interaction with it, just leave it out of the form.  That will also ease some of your other headaches, your xlsform has a repeat for the Event Log which you said doesn't have a relationship in the feature service. That will cause your form to error out since Survey123 is looking for a repeat that doesn't exist.  

[ChrisFerner_YT]

Thanks Tyler! I mistyped relate instead of repeats for the two tables Event_Log and Species_List. So those two could point directly to the child service. I did publish it all w existing relates (1:M) from Pro. For the URL the Event_Log ends with "&sublayer=1" after the item id. If I'm understanding right you are saying to replace that with "/1"? 

And thank you for the clarity about being able to remove fields from my survey that do not need to be populated. I was worried I had to include all the fields and hide them based on the very few examples I'd found.

[TylerGraham2]

Here's an example of the submission url setup that I use to point to a specific table in a hosted feature service for the main body of a form.  I created and published the feature service using Pro. In Survey123 Connect I created the survey using the feature service and by default the submission url points to the feature service without any layer ids. 

The way ours works is that users enter data for layers in Field Maps and then use Survey123 to complete the Monitoring Notes and other tables. In Survey123 the main body of the form is MonitoringNotes, which if I go to the feature service's REST page in AGOL, shows it has an ID of 4.  In the Settings of the xlsform you can see at the end of the submission url that I added the layer ID at the end and that form_id name matches the MonitoringNotes table name.  If I don't add a layer ID to the submission url, Survey123 looks for layer 0 as the main body of the form

In my case, the users don't interact with any of the layers shown below in Survey123, only the tables, so I don't reference the layers at all in my xlsform and they become essentially invisible to Survey123. But let's say I wanted another form for No_Monitoring.  I'd create a new form from the feature service in Connect and rename the form_id to No_Monitoring and add /3 to the submission url.  Then I'd have a form for the MonitoringNotes and a separate form for No_Monitoring that are both putting data into the same feature service.  

  

[PhillipHinz_1]

Hi Chris

I think I understand your situation.  Please clarify if any of this is off:

1. You have five separate Survey123 Connect surveys that run off of this same geodatabase.
2. You have 1 feature layer that is the parent and 5 tables that are the children, plus 3 of the 5 tables also have repeats of their own to other tables (grand children?). 
3. The two tables that don’t have repeats are EventLog and Species List.
4. Are the five separate surveys in different Survey123 Connect documents or is there a question within the form where the user selects which survey they want to do and then from that response different questions appear?

I worked on a similar situation which inform the following questions (I think the problem involves your third bullet point):

1. At what point is it not working? Does it not work within Connect or is it not publishing?
2. You mentioned that you made the GlobalIDs and GUIDs, but did you establish the relationship classes within the database in Pro? You have to do this before creating the Survey123 Connect form, otherwise the form will not pick up those relationships and you will not get the repeats populating when you are creating the new survey from the feature services.
3. Are all of the related tables (parents, children, grandchildren) in that one geodatabase? They should be.  All tables and features must be in one file geodatabase if they are related or are being submitted to.
4. Regarding point 3 above, you should only be using one submittal URL. Connect only reads that one row and the URL should be for the feature layer. It knows what is related to what from looking at the relationship classes within that database.  I think this might be where you are getting the problems.  It is not clear in the documentation, so there is no way you could have known.
5. Also regarding your third bullet point, are EventLog and SpeciesList related to the feature class or are they totally separate? If they are related to any of the other tables or the feature layer, you need to establish the relationship class in Pro first, then you do not have submission issues.  You only use the submission URL of the child table, if nothing else is being submitted – no changes to the feature layer or any other table. Then you would use a separate form for that situation.

I hope this makes some sense.

Finally regarding your last bullet point, it is easier processing wise if you make the relationship classes and relates in pro then strip the Survey123 Connect form to only include what you need for each form. In other words, make the surveys as simple as possible use as few relates as possible, have separate survey forms rather than hiding who sections. Only keep the tables you need for the form you are using, it will slow down processing if there is a lot of “unused” hidden questions.  Mind you, from a work flow perspective it totally makes sense to have one survey form that has different sections that are hidden until needed – that way field users are only downloading one survey rather than five.  My advice is to try to fix the stuff I mentioned above, then see if you get slow down. If the stuff I said doesn’t get it to work then make five separate surveys without big hidden sections.

Best of Luck,

Phillip

[ChrisFerner_YT]

Hi Philip - Thanks for the reply! Your summary points 1-3 are spot on. #4-I need them to be 5 separate survey's bc field staff visit pre-collected features then fill out the surveys sometimes at the same time. But the surveys were not publishing. I was starting w Event_Log since I thought it would be simple since it didn't have repeats but now with Tyler's tip above I fixed the URL and it's working okay now.

I did create the relationship classes in Pro before publishing. (Learned the hard way that my table name alias's can't have spaces) and all parent, children, and grandchildren 🙂 tables are all in the same GDB. 

Thanks for your help!