I do not think it is possible to create a M:1 relationship but I saw this text in the help so wanted to check.
Pluralize the origin feature class name if it is a many-to-one or many-to-many cardinality, and pluralize the destination feature class name if it is a one-to-many or many-to-many cardinality.
Is this a typo or is there a way to pull it off? I tried just making my child the parent but then Field Maps will only let me create a child and not a parent at all since it assumes the parent is the 1 (plus there is no filter related types setting like in Collector). So I need a way to be able to create multiple lines in Field Maps and then link it to one table record that is created in Survey123.
Why would I do this? Well we have a legacy data set that is multipart. You cannot create mutlipart in any app and all the other issues with multipart. They did this since we often have a stream and minor offshoots that have the same answers for data collection. If we go singlepart then I need to have 2-4 lines that connect to one table of answers. So divorce the geometry from the data. We would like to be able to create either one first. So I could go out and answer my questions in 123 first or create my geometry in Field Maps first. Field Maps forms cannot do what I need them to since they are still very basic. 123 cannot create lines or polygons while offline without a TPK (with lots of contractors its not feasible) and the interface is not very good in 123. Also sometimes we load in the lines for existing data which may happen before or after they go out.
A M:M is too much overhead for us.
I will pass keys from Field Maps to 123 using a URL and can pass keys from 123 to Field Maps via URL. But this plan fails if I have the answers table as the parent since Field Map simply will not let me create a child with no parent. This forces us to have a form before the geometry. I could just skip the relationship until we move it to production but it is super handy to have Show Related during the field season.
Open to any ideas on this. Each way I test there is some issue. There is the new Hosted feature layer views but I do not think this will help me in Field Maps at all.
Note I can create a 1:M and then just create features to make it a M:M and it does not care. I know that management will be crazy but if I leave off any messaging it may be ok.
What if you write it as a SQL view and then export the view to a standalone fgdb and use that to publish as you hosted feature service? The update process may be a bit tedious but it is possible.