Allow Select Multiple Questions in Field Maps

[RogerCleaves1]

We would love to be able to implement select multiple type questions in Field Maps. We currently have a use case where field staff need to select multiple types of waste found on a site and record contextual information for each one. 

This is the current design in Survey123, but we would love to migrate this all into one single app instead of using Collector for visibility in the field, and Survey for collecting the data.

[erica_poisson]

I would love to see this implemented in Field Maps. I do not think it would in any way replace Survey123 (there are just so many other things that make that fantastic), but it would be great to help streamline certain workflows if we could just use one platform (Field Maps) to collect data, like Roger mentions. 

[BenSmith6]

This is desperately needed in Field Maps, Survey123 (as Erica mentioned) does so much more that I don't think it would impact it's use at all

[CinthiaEichhorn]

This is NEEDED.  Many wildlife biology surveys are map centric, and have a need for choosing multiple answers.  For example: the condition of a vhf transmitter that has been found. 

The vhf transmitter's condition can be: chewed, curled, torn apart, bite marks, or a combination of these four options.  There are ways to create this question/response to fit into Field Maps, but a select multiple type would be the most intuitive for the field users.

Moreover, if there was a select multiple type in field maps, it would be more efficient to implement than the current Collector calling a S123 form combo.

[SimoneMoretti_MRC]

This is an urgent need for my data collection too. Hoping this will be available in the next update

[MatthewGuilliatt]

This is also vital for my data collection. 

Survey123 is great, but it is weak in displaying reference layers, fieldmaps is great for displaying reference data, but we can't capture the information we need to.

[SSMGroup]

This should be top priority!! 

Along with Choice Filters. 

I cannot make the switch to field maps until these functionalities are available. 

@DougBrowning  Maybe you can help get this post suggestion noticed by Esri. This would be a wonderful addition to Field Maps, and it's really needed.  I'd love for my users to be able to stay within one app for the workflows I create.

[Anonymous User]

We're well aware of this request, it's one of the most requested form features (along with calculated values and contingent values). It's not something we're planning to implement in the next quarter but perhaps later in 2022 we could. Here's some questions we have for you that might help us:

• Survey123 implements this as a comma delimited list of values stored in a string field. This can make it difficult to re-use in other areas of ArcGIS. For those of you who use Survey123:
• How do you use the captured data for these fields?
• Do you show the layers in other apps/maps besides Survey123?
• Do you use hidden fields & calculations to split the choices into separate fields?
• Do you use Arcade in Pop-ups and Dashboards to format the data?
• Would you expect to be able to create a multiple choice element for existing fields?
• If so, do those fields have existing coded value domains? Are they string fields or integer fields?
• Would it be beneficial to have a multiple choice UI/UX that stores each choice in a separate "boolean" field instead of a comma delimited list?
• How many choices per question are anticipated?
• Would you need to add or remove choices over time?
• If so, should that affect previously collected data?
• Would you need to deprecate choices over time?
• Would you need to edit an existing choice name/values?
• If so, should that affect previously collected data?
• Do the choices needs any additional information displayed with them, like a description? Or is the value/name enough?
• If so, can you provide a specific example?

[RogerCleaves1]

@Anonymous User Here's the responses to your questions! I'd be more than happy to talk through our specific use cases.

• Survey123 implements this as a comma delimited list of values stored in a string field. This can make it difficult to re-use in other areas of ArcGIS. For those of you who use Survey123:
  • Do you show the layers in other apps/maps besides Survey123? 
  • We use a view of the data in some internal and external dashboards
  • Do you use hidden fields & calculations to split the choices into separate fields?
  • Not right now, but have experimented with that as an option to parse the data
  • Do you use Arcade in Pop-ups and Dashboards to format the data?
  • Yes, we use Arcade to parse the data based on the types selected in the select multiple field
  • 
• How do you use the captured data for these fields?
• We use the data to provide summaries of which type of HHW or Asbestos is collected at each facility.
• Would you expect to be able to create a multiple choice element for existing fields?
• No
• If so, do those fields have existing coded value domains? Are they string fields or integer fields?
• Would it be beneficial to have a multiple choice UI/UX that stores each choice in a separate "boolean" field instead of a comma delimited list?
• That would make it easier to work with the data for visualizations and other data exploration
• How many choices per question are anticipated?
• For this use-case, at least 20 options would work
• Would you need to add or remove choices over time?
• Not necessarily, but it would be nice to have that option
• If so, should that affect previously collected data?
• No
• Would you need to deprecate choices over time?
• No
• Would you need to edit an existing choice name/values?
• No
• If so, should that affect previously collected data?
• No
• Do the choices needs any additional information displayed with them, like a description? Or is the value/name enough?
• Value/Name should be good enough for us
• If so, can you provide a specific example?

[erica_poisson]

@Anonymous User  -

Hoping to chime in here with some answers to your questions as this is something we'd also love to see implemented in Field Maps. If this was added, we'd be able to simplify some field workflows by removing the Survey123 component (which is used if we need to select multiple values).

• Survey123 implements this as a comma delimited list of values stored in a string field. This can make it difficult to re-use in other areas of ArcGIS. For those of you who use Survey123:
• How do you use the captured data for these fields?
• Do you show the layers in other apps/maps besides Survey123?
  • Yes - we generally display collected data in Dashboards.
• Do you use hidden fields & calculations to split the choices into separate fields?
  • No - we store the data as comma delimited and then work with it later using Arcade Data Expressions or something like R.
• Do you use Arcade in Pop-ups and Dashboards to format the data?
  • Yes - we use Data Expressions in Dashboards to break the data out for charts.
• Would you expect to be able to create a multiple choice element for existing fields?
• Primarily this would be used to migrate existing (simple) workflows from Survey123 to Field Maps. We have existing domain values assigned already and would like to just "check off" a select multiple option to allow for multiple choices to be selected. Similar to the experience when building a Survey123 form in Connect  "on top" of an existing feature layer. 
• If so, do those fields have existing coded value domains? Are they string fields or integer fields?
  • Yes to existing coded value domains - both string and integer fields, however string is much more common.
• Would it be beneficial to have a multiple choice UI/UX that stores each choice in a separate "boolean" field instead of a comma delimited list?
  • I'd be interested to see how this would affect schema design. It sounds nice, but with the capabilities of Data Expressions, I am unsure if I'd give a hard and fast "yes" here without knowing more about how the schema is affected for existing data layers. 
• How many choices per question are anticipated?
  • I'd agree with @RogerCleaves1  that ~20 choices would be adequate when thinking of my existing workflows that I'd like to migrate. 
• Would you need to add or remove choices over time?
• Potentially. 
• If so, should that affect previously collected data?
  • No - if a choice is added or removed, all existing data with that value should not be changed.
• Would you need to deprecate choices over time?
  • Potentially - same response as above.
• Would you need to edit an existing choice name/values?
• Ideally not, but it is always possible. 
• If so, should that affect previously collected data?
  • It would be nice, but this can also be dealt with via Pro.
• Do the choices needs any additional information displayed with them, like a description? Or is the value/name enough?
• It would be ideal, in my opinion, to have a similar set up to Survey123 where you have the stored code and the label that is shown to the user in the application.
• If so, can you provide a specific example?
  • We have coded values for our subbasins - 5 = Ball Brook. We don't want a list of numbers to show up for users, we want the list of labels that correspond. Another example would be for stream codes - the description is much more useful for field staff. 

[KyleLandon]

• Survey123 implements this as a comma delimited list of values stored in a string field. This can make it difficult to re-use in other areas of ArcGIS. For those of you who use Survey123:
• How do you use the captured data for these fields?
• Do you show the layers in other apps/maps besides Survey123?
• Do you use hidden fields & calculations to split the choices into separate fields?
• Do you use Arcade in Pop-ups and Dashboards to format the data?
• Haven't used Survey123, doesn't  meet needs.
• Would you expect to be able to create a multiple choice element for existing fields?
• If so, do those fields have existing coded value domains? Are they string fields or integer fields?
• Since it's not available as a way to collect data, I haven't made fields to do this. I think coded value domains would be most fail-safe/elegant. A good way to capture "Other" would be nice. We should be able to have a conditionally visible field to capture it.
• Would it be beneficial to have a multiple choice UI/UX that stores each choice in a separate "boolean" field instead of a comma delimited list?
  • I can see how this may be helpful, probably not as big a difference maker if using coded domains
• How many choices per question are anticipated?
  • Maybe a dozen or so at most
• Would you need to add or remove choices over time?
• Probably.
• If so, should that affect previously collected data?
  • I think it's not unreasonable to say we'd have to script repairs or fixes as needed.
• Would you need to deprecate choices over time?
• Would you need to edit an existing choice name/values?
• Most likely
• If so, should that affect previously collected data?
  • yes, but I'd think one could script the change or manually fix.
• Do the choices needs any additional information displayed with them, like a description? Or is the value/name enough?
• Value/Name is fine
• If so, can you provide a specific example?