Create a new Hosted Feature Service Domain Type: codedvalueMultiSelect

[JohnMDye]

Currently, ArcGIS Applications other than Survey123 are unable to support multi-value selected due to limitations on the Hosted Feature Service definition. That is, there is no way to indicate whether or not a value should be 'selected' or  'unselected' because such a value type does not exist within the hosted service definition.

Take this 'Payment Forms' field I created in a Hosted Feature Service as an example:

{
 "name" : "PAYMENT_FORMS", 
 "type" : "esriFieldTypeString", 
 "alias" : "Accepted forms of payment", 
 "sqlType" : "sqlTypeOther", 
 "length" : 50, 
 "nullable" : false, 
 "editable" : true, 
 "visible" : true, 
 "domain" : 
 {
 "type" : "codedValue", 
 "name" : "Point layer_PAYMENT_FORMS_8ff94d6b-7b8c-4f0e-8838-2fb72098a535", 
 "codedValues" : [
 {
 "name" : "Cash", 
 "code" : "CASH"
 }, 
 {
 "name" : "Check", 
 "code" : "CHECK"
 }, 
 {
 "name" : "Credit", 
 "code" : "CREDIT"
 }, 
 {
 "name" : "Money Order", 
 "code" : "MNY_ORDER"
 }, 
 {
 "name" : "Certified/Cashier's Check", 
 "code" : "CERT_CHECK"
 }, 
 {
 "name" : "Debit", 
 "code" : "DEBIT"
 }, 
 {
 "name" : "Wire Transfer", 
 "code" : "WIRE_XFER"
 }, 
 {
 "name" : "Apple Pay", 
 "code" : "APPLE_PAY"
 }, 
 {
 "name" : "Google Pay", 
 "code" : "GOOGLE_PAY"
 }, 
 {
 "name" : "Venmo", 
 "code" : "VENMO"
 }, 
 {
 "name" : "Zelle", 
 "code" : "ZELLE"
 }
 ]
 }, 
 "defaultValue" : "CASH", 
 "description" : "null"
 }

I think anyone looking at the list of values above could see what one would normally be trying to do here. Offer a list of values from which multiple could be selected or unselected, depending on the forms of payment a vendor accepted. However, it's not possible to do this with the current Hosted Service definition.

What I'm proposing is that the the 'codedvalue' domain type be forked, to create a  'codedvalueMultiSelect' domain type. Such a domain type would be identical, except that it would add a new boolean property ('isSelected') would be added to each name-code pair in the 'codedValues' array. Which would result in this structure for the above example:

{
 "name" : "PAYMENT_FORMS", 
 "type" : "esriFieldTypeString", 
 "alias" : "Accepted forms of payment", 
 "sqlType" : "sqlTypeOther", 
 "length" : 50, 
 "nullable" : false, 
 "editable" : true, 
 "visible" : true, 
 "domain" : 
 {
 "type" : "codedvalueMultiSelect", 
 "name" : "Point layer_PAYMENT_FORMS_8ff94d6b-7b8c-4f0e-8838-2fb72098a535", 
 "codedValues" : [
 {
 "name" : "Cash", 
 "code" : "CASH",
 "isSelected" : true
 }, 
 {
 "name" : "Check", 
 "code" : "CHECK",
 "isSelected" : true
 }, 
 {
 "name" : "Credit", 
 "code" : "CREDIT",
 "isSelected" : true
 }, 
 {
 "name" : "Money Order", 
 "code" : "MNY_ORDER",
 "isSelected" : false
 }, 
 {
 "name" : "Certified/Cashier's Check", 
 "code" : "CERT_CHECK",
 "isSelected" : false
 }, 
 {
 "name" : "Debit", 
 "code" : "DEBIT",
 "isSelected" : true
 }, 
 {
 "name" : "Wire Transfer", 
 "code" : "WIRE_XFER",
 "isSelected" : false
 }, 
 {
 "name" : "Apple Pay", 
 "code" : "APPLE_PAY",
 "isSelected" : true
 }, 
 {
 "name" : "Google Pay", 
 "code" : "GOOGLE_PAY",
 "isSelected" : true
 }, 
 {
 "name" : "Venmo", 
 "code" : "VENMO",
 "isSelected" : false
 }, 
 {
 "name" : "Zelle", 
 "code" : "ZELLE"
 "isSelected" : true
 }
 ]
 }, 
 "defaultValue" : "CASH", 
 "description" : "null",
 "isSelected" : true
 }

As you can see, the only things that have changed are that domainType has changed to 'codedvalueMultiSelect' and each item now has a boolean 'isSelected' property which is set to either true or false, depending on whether or not that value should display as selected.

This structure would allow other ArcGIS applications such as Collector, Workforce, OpsDashboard, WebApp Builder, Configurable Apps and pretty much all others to start supporting the much desired 'multi-select' functionality without having to do any weird CSV parsing or custom syntax management. All they need to do is look at the domain type and if it is 'codedvalueMultiSelect', then they need to read the 'isSelected' property for each domain value. From there, they can decide how to display selected and unselected values depending on the experience they want for their application.

Some might offer that this is already supported by Survey123. I realize that. This idea is requesting a new domainType so that other applications can offer the same functionality without having to do the custom CSV parsing that Survey123 does in order to offer that functionality. In fact, I'd wager that if this new domain type were created, Survey123 would switch to use this instead as it would be much easier to work with than what they are doing now. This would also allow multi-select to be supported across the entire ArcGIS Platform in all applications, rather than just in Survey123.

[ArsenBeglaryan]

I am surprised, how it is still not possible in 2022.

[easchwe]

This function is absolutely needed. The flagship platform, ArcGIS Pro should not have this limitation. I have a list of 18 departments that may need to be involved in a process tracked using an SDE feature class. The data entry is done by multiple staff members across departments. It is impossible to set up a domain value with all the possible combinations, since any or all of the departments may be involved, and the names are to long and similar to enter free text without tons of errors. Select multiple domain is the only way to accomplish this. The only other option I can see is to have a yes/no field for each department which would add an additional 18 fields (!) to an already large table.

A very simple and elegantly coded solution was delivered in the initial comment three and a half years ago, c'mon... Please add this functionality!

@KoryKramer 

[asimmons]

Hello from 2024. Any word on when this feature may be added? 

In my agency we would really love to select multiple domains for managing trail data in ArcGIS Pro and AGOL. 

[helf0023]

It would be useful for folks I work with to be able to select multiple domains as well. Recently, our team requested the ability to select multiple team members' names when collecting data in the field regarding who was performing chemical or manual treatments of invasive species onsite.

[Joshua-Young]

This has often been a defining limitation of ArcGIS that has cause other departments in my organization to go find a different solution to meet there business needs. It seems like this is a simple and common business need. I recently created a CIP dashboard and had to come up with an interesting workaround so users could see all the different types of infrastructure improved by a project without double counting the project. It would be easier to be able to select "Transportation; Water Distribution; Wastewater Collection;" in one field and be able to filter by any one of those values. Something else that would be cool would be to create symbology for the individual domain values and have ArcGIS combine the colors in the symbology based on what values are selected.

I will also echo that the original poster provided a simple solution to enable this functionality.

[DavidSolari]

I've had at least one project that would ideally use the standard editing tools (and Field Maps) get converted to a Survey123 hackjob workflow due solely to a lack of a multiple-choice domain. Making this a standard geodatabase feature would lead to greater adoption in other parts of ArcGIS. While I'm here, here's a user story to help development:

1. Bob needs to collect which birds and which fish are in all the lakes in the city park. The lake assets are digitized ahead of time and he only needs the latest state, so a multi-choice domain for the "birds" and "fish" fields on those lake polygons are all he needs.
2. The "birds" field is already there as a text field and can't be altered, so Bob creates a "BirdSpecies" multi-choice domain in the Enterprise Geodatabase for "Text" fields. He enters a 2-character code for each species and a full text description.
3. The "fish" field will be a new field and Bob wants to keep his data fast and compact, so he creates a "FishSpecies" multi-choice domain for "Short" fields. Bob enters the description of each species and Pro auto-populates a numerical code, ensuring that for each description "n" the code is "2^(n-1)". Bob can alter the codes by hand but Pro will ensure that no codes have non-power-of-2 values. It will also ensure that no more than 16 codes are assigned for this "Short" domain; Bob can step up to a "Long" type if he needs up to 32 choices.
4. Bob stops the web services, adds the new field, applies both domains and starts the services back up. The REST endpoints for these services now show the multi-choice domain options for the appropriate fields.
5. Alice is configuring the Field Map for this collection project. When she adds the lake layer to the map and configures the smart forms the "birds" and "fish" fields now have a "checkbox" form element by default. Alice can change this from a dropdown list to a radio list if needed. She can also write Arcade expressions using the new "HasCodeInField" function to hide field groups or calculate other fields if a certain bird or fish is selected in the form.
6. Steven has to create a Survey123 form for the lakes to meet a client mandate. He tells Survey123 Connect to prep the form based on the "Lakes" layer and the form automatically has a "select_multiple" question and matching list for the "birds" and "fish" fields.
7. Ricardo collects a new lake in Survey123 and updates an existing lake in Field Maps. In both cases, the raw value of the "birds" field is all the codes in a comma-separated list, just as Survey123 does with a "select_multiple" question on a domain-free text field, and the "fish" field holds the bitwise OR of all choices as a single number.
8. Veronica has a custom export script tool that needs to handle these new domains. During the export, her script grabs the "Domain" object for each field and calls the "codeToDesc" function with the raw value as a parameter to get a list of descriptions that she can process further. She could also use the "arcpy.da.ConvertDomainCodeToDesc" function with the raw value, the workspace path and the name of the matching domain to acheive the same goals.