Latest Contributions by EvanOlivier

Currently, groups in Survey123 Connect XLSForms are merely cosmetic organizers for the forms, while repeats are utilized specifically for related tables. For workflows that are based on existing feature services, it would be greatly helpful to be able to replace the "begin repeat. end repeat" rows with "begin group, end group" without encountering publishing errors where "parent layer ID is not found for <> table."  Specifically, the workflow for asset management where collector is utilized for all inventory, and survey123 is utilized for all inspections, this would be highly useful. Example: You have published a feature service from your SQL database that includes a Parent Structure Feature Class {Utility Poles} with a series of related pole component tables {PoleComp_Risers} with related inspection tables {PoleCompRisers_Inspection}. Survey will automatically create nested repeats where component inspections are nested within the component inventory tables. To ensure field crews are using collector for all inventory tasks, we hide the inventory table questions and utilize :null field type questions as qualifiers for how many inspection repeat_counts to allow (3 riser inspections for 3 risers inventoried in collector, no more no less).  As a default, unlimited repeats are allowed per repeat when generating an XLSForm from an existing feature service. This is a great capability, but can be problematic in this workflow as it would allow field users to potentially delete entire component groups or add too many inspections per component. Currently, when utilizing existing feature services, you have to add <repeatname>_count meta data fields (text type, null allowed, 255 character length) to your parent related tables (inspectiontable_count field inside the component inventory table), generate form, and delete those fields before you are able to successfully utilize the repeat_count column with static values or calculations without throwing publishing errors. This is not ideal from a database engineering perspective, as these fields take up database space and are not relevant for any reason other than the function of the Survey123 field application. We have to ensure these fields are hidden from all our end users on portal, desktop and related applications to reduce confusion. This idea would allow us to bypass the additional creation of inventorytable_count meta data fields (5 at least for each component) that have to be added to the parent feature class (Poles) to be able to restrict the end users from deleting component groups or adding additional inventory when inventory is only meant to be done in Collector. By allowing Group questions to function similarly as repeats, we could change the main ComponentRiser inventory table into a group that still contains a nested repeat for inspections (CompRiser_Inspections) while simultaneously restricting the "repeat" interactive object at the bottom of the main group (trashcan button, arrows and plus button) without having to add additional _count fields to a feature class in our SQL. This way, the main group of Riser Assets would not show any repeat options at the bottom of the group and the Riser Inspections would have the number of repeats automatically set from qualifying null type questions (How Many Risers Are There? 1,2,3,4).  Then, we could hide all inventory questions except for a select few that are carried into the form by custom url from popups in collector for read only referencing purposes effectively allowing our field users to utilize collector for all inventory tasks and survey for all inspection tasks. A possible solution to this would be to enable null field type to change the function of a begin group question to be cosmetic in function, while leaving that blank would allow groups to function the same way begin repeat questions currently do for related tables in the schema. Thank you for your time and consideration, we love Survey123! ... View more