AnsweredAssumed Answered

Populating Select-One from Separate Feature Service or Related Table

Question asked by clrogers on Jun 8, 2018
Latest reply on Jun 12, 2018 by clrogers

James Tedrick Ismael Chivite Elvin Slavik

 

Hello Survey123 Gurus,

 

I'm looking for information to see if there is a way that I can reference one Feature Service layer or Relational Table to drive some UI components in a Survey while posting that survey to its own Feature Service layer.

 

Here's the use case,

 

I have an existing Feature Service that contains all the Wrecker Companies in Oklahoma that DPS uses for vehicle tows. I have created an app that allows our Wrecker Services Division to keep this updated so that it is always current.

 

I have created a Survey that allows a Wrecker Service to tow a vehicle and log this service event into a separate Feature Service however; since it also collects the Company information as well as the Drivers data I'd like to be able to reference other Feature Service layers to drive the contents of let's say a Dropdown UI in the Survey.

 

Can this be accomplished to use another Feature Service or Relational Table as a Reference Table/Source for a separate survey? I was thinking Push/Pull referencing the Features Service or Relational Table as the source but I've either missed that documentation somewhere or it doesn't and exist and therefore may not be a current capability.

 

Looks something like this in pseudo code...

 

1) User Opens the Wrecker Service Log survey

2) The survey loads a Company list from a separate feature service called Wrecker Service Companies

3) User selects a Company from the list

4) The survey loads a list of Drivers from a separate feature service or related table called Wrecker Company Drivers

5) User selects a Driver from the list

6) User submits all data back to the survey's own feature service layer called Wrecker Service Log

 

Moving forward the Company and Driver Data will be two separate layers/tables though related in either a many:many relationship or  1:many (one company many drivers) and 1:many (one driver to many companies) with a join table/layer between them for 5th Normal form considerations though I'm aware this may still be a difficulty within the current AGO Environment.

 

Thanks for any/all assistance and advice in advance!

 

Regards,

Chris

Outcomes