How to only send related data to an existing feature service?

[Jesse]

I am attempting to send survey data to an existing feature service. The service is set up so that there is one feature layer called MonitoringSites with four related tables. None of the related tables have or need geometries.

I only want to send data into the related tables with the survey, and I want them to be related to existing monitoring sites. Not only that, but in some of the related table repeats, I want to submit multiple records for existing monitoring sites during the same site visit. For example, in one visit, surveyors only need to fill one related entry for SiteConditions,  but they will need to take multiple MosquitoSamples. 

Using a survey built from the attached spreadsheet in Connect, I can successfully add related records, but when I look at the results in our enterprise database, the data are related to a ghost MonitoringSite. I think the survey as it currently stands just creates a new null geometry with every submission and automatically relates the repeats to that ghost geometry.

Is there a way to prevent this from happening while still maintaining a single survey?

----------------

EDIT#1

Here's the structure of my service/related tables, and my requirements for collection.

MonitoringSites

    |_ SiteConditions (1:M, one per site visit)

    |_ MosquitoSamples (1:M, ten per site visit)

    |_ DiversitySamples (1:M, undetermined per site visit)

    |_ WaterQuality (1:M, one per site visit)

EDIT#2

My original idea did not work, I don't think it's possible to only send related data. I ended up making the SiteConditions table a feature class with all the other tables related to that one rather than the MonitoringSites. It's a workaround that got me where I needed to be.

[ChristopherCounsell]

You have two options:

1. Use the Survey123 Inbox to pull down your Monitoring sites, and then add related records.
   • This is 'updating' the point layer but you are 'adding' related records..
   • You can set the repeat_count to 1 for site conditions. to limit one related record
   • Configure editing capabilities, questions and field editability on the parent table to not allow users to delete/overwrite monitoring site data at the parent geometry level
   • use bind parameters on the repeats to allowAdds=True
   • Allows for any number of single-level repeats to be completed, as you have currently designed it
2. Use a Survey123 custom URL to launch a survey from field maps and target one related table at a time 
   • Create a new survey form from the existing service, delete all questions outside the target repeat and add a hidden parentglobalid question
   • Survey123 Monitoring site > Pop-up > custom url to launch survey form, pass monitoring site globalid into parentglobalid field.
     You are now submitting a survey against the repeat directly. adding a new record into that table.
   • You can nest the tables (put the samples repeat within the site visit repeat). if you don't, you'll have to design a survey for each related table + launch a new survey form every single time. i.e. field maps popup > site condition survey. Popup url again for each sample survey 
   • Users will then fill out the target repeat directly and add records against it. If you have a nested repeat, users can fill out that repeat as part of the one submission.

[Jesse]

Thanks for your reply!

I already employ that second workflow, and I'm pretty sure the steps you laid out are exactly how I structured the survey, but that is what's leading to those ghost geos being created.

In my original survey design, I have repeats for all related tables, and I send the results to the MonitoringSites form_id in the settings tab. If I remove the repeat around SiteConditions, and change the form_id to that table, I get an error when attempting to publish saying that Parent layer ID 1 not found for table WaterQuality. I attached those changes to this post.

(See my post edit for the structure of the service/repeats)

Was that the change you were suggesting?

[ALBJORGUI]

Hi Jesse, 

Did you find a solution to this? I'm currently trying to do something very similar but my feature class fails when I try to publish as survey123 connect tells me that the begin repeat field does not exist as a field in the feature class

[ChristopherCounsell]

Begin repeat = not a field. It's the name of the related table.

You are getting an error as the related table does not exist in your target
service.

If it was republishing the original hosted feature service and survey that
created it, survey123 connect would prompt you to rewrite the feature
service as part of the update.

Targeting an existing service, you need to ensure the XLSForm matches the
target service. So your feature service needs to contain the necessary
fields and related tables (repeats)

[ALBJORGUI]

Hi Magisian, 

I do have on my zls all features and tables and the schema for the survey looks fine to me however I still get an error.