Standalone Table In Enterprise Being Used In Survey 123

[GarretGiordanoTOLE]

I am trying to set up a survey in Survey 123 that populates a stand-alone table in a service. Both items are in an Enterprise FGDB.

The table is related to the feature class that it is in the feature service with. I would publish the table on its own in a service, but ESRI doesn't seem to allow that in an Enterprise environment for whatever reason.

The issue I am having are as follows:

Survey 123 is not picking up the stand alone table in the service. I have tried replacing the item ID from portal for the table rather than the Polygon Feature Class in the XLS form. It has no effect. How do I get Survey 123 to look at the stand alone table instead of the Feature Class.

[jcarlson]

In Survey123 Connect, you change the form_id in the Settings tab.

https://doc.arcgis.com/en/survey123/desktop/create-surveys/xlsformsettings.htm#ESRI_SECTION1_0930884...

[GarretGiordanoTOLE]

Yeah, I have tried that too. It changes the layer name in Layers/Tables in 123 Connect but then the Schema is from the polygon feature class still.

[DougBrowning]

Submission URL is the root of the service then the form_id has to match the name of the table in the service exactly.  Maybe some screen shots would help.

[MichelleWilliamsERM]

Is there a reason you can't build all the fields (from your table) into Survey123, then APPEND the table to the hosted service? 

[GarretGiordanoTOLE]

The Feature Classes are registered with our server running through an ArcGIS Server Datastore. We want this to relate back to a polygon feature class in our SDE instantly. The items being collected are non-spatial. They could be made spatial but that would create undue work for the end user and we would likely get pushback on that. 

Honestly, this is acting as an asset management system of sorts. We have a building polygon and we are trying to relate a service record form to that polygon. The Domains are all set and the relate works great. It is truly just an input issue at this point. I'd use field maps, but once again we are trying remove the spatial component for the end user. 

I apologize if I am not following where you going with that.