Hi James, Carmel, Thanks for your responses, that's useful to know.
What might be a useful feature enhancement (at least for me) would be to have the option of converting some of the choices into a domain / subtype in the feature service. I understand you can't convert all of the relationships because as you say the complexity is not supported by the feature service.
Just for completeness I'll provide an example of the type of thing I'd like to do. Say you had a domained field in survey123 that asked you to choose a fruit. You pick apple. The next question asks what variety of fruit it is. Because you selected apple in the previous field it restricted the responses to varieties of apple. If you'd picked pear it would have restricted responses to varieties of pear. Currently if you publish this as a feature service, all of the drop down choices on varieties of apple or pear do not make it through as a domain (even if it were to list everything - both apples and pears). This means that if you needed to edit or create features in that feature service in any other app (geoform, arcmap, pro etc.), there would be no dropdown suggestions for variety so the user would be free to enter anything they wanted. If instead you had the option of taking the choices and mapping them to a domain, it would save time adapting in arcmap / pro, and mean that the user can still only pick from a list. This would in turn mean that somewhat higher quality data is recorded (no typos etc.) although they still might be able to put a pear variety under an apple choice (subtypes would help here).
Your suggestion should work - I can copy the feature service into a gdb in the template, and then have the users copy and paste local points into the service - There would then be a QA stage to check that there are no duplicates from points coming in from survey123. The only potential issue I can think of is that it then creates a requirement to update the gdb any time the original schema changes.
Having done a little more searching, this thread also seems related: Sample Form With Multiple Feature Templates And Subtypes. · Issue #96 · Esri/Survey123Community · Gi... It helps me understand the pros / cons with using subtypes etc. in survey123 when they were designing it. There's a couple of things to try with adapting the feature service after its been published that I can also give a go - it's close to your workaround Carmel, but it looks like I can re-connect the adapted feature service back to survey123. I suppose this may also have the issue of having to republish if the schema changes.
...Unless you have any other suggestions? I realise it's probably not a very common use case that people might have more than one preferred way of entering into the same schema if survey123 does it so well, but there are potentially reasons for doing so, and I'm just trying to find the easiest way to set up a workflow that other users can follow.
Thanks again.
