Survey123 - Choices list

[Anonymous User]

Hello,

Quick question on the choices tab. Is it possible to have the following setup within the choices tab; please look carefully.

list_name	name	label
Bat_Freq_Choice	172.064	172.064
Bat_Freq_Choice	172.091	172.091
Bat_Freq_Choice	172.121	172.121

Notice that there are "dots" or "decimal points" within the "name" column within the sample above! Also, please note that this is within a functioning Survey123 form that has been used on one of my projects. I did not realize that I had inadvertently forgot to replace the "decimal" with an "underscore" prior to posting the survey for use.  According to this help documentation though; this should not be possible or am I miss interpreting the help documentation?

Here is the first portion of the help documentation below

Choices worksheet

This worksheet is used to specify the answer choices for multiple choice questions. Each row represents an answer choice. Answer choices with the same list name are considered part of a related set of choices and will appear together for a question. This also allows a set of choices to be reused for multiple questions (for example, yes/no questions).

The choices worksheet has three mandatory columns: list name, name, and label.

• The list name column lets you group together a set of related answer choices. Choices with the same list name will be presented as the set of answers for a question.
• The name column specifies the value that will be persisted in ArcGIS when that choice is chosen. Values in the name column do not accept special characters.
• The label column shows the answer choice exactly as you want it to appear on the form. Alternatively, label translation columns can be used.

One thing to keep in mind when authoring forms in Excel is that the syntax you use must be precise. For example, if you write Choices or choice instead of choices, the form won’t work.

Here is the information that is contained within the link for "special characters"

Special characters

These characters can't be used in the name of a question, or in the name field for a choice list.

Special character	Name
	Space
,	Comma
;	Semicolon
-	Hyphen
/	Forward slash
$	Dollar sign
.	Dot
(	Opening parenthesis
)	Closing parenthesis

My survey should not be usable according to the help documentation, but it worked perfectly on a project that we completed this summer. However, I am getting ready to re-purpose this survey for use on another project that starts next week. I don't want to assume that the survey is "ok" to use and have issues with the form once my field crews start to use the form.

I have the opinion of making the edit for switching the "dot/decimal point" within the values of the "name" column to an "underscore" and thing should be good to go.

Any information would be greatly appreciated.

#ismael chivite‌ #james tedrick‌

[JamesTedrick · Accepted solution]

Hi Mike,

Doing some testing, it looks like the documentation is in error - spaces are the only character that generates a warning (not an error).  The other characters are fine to use in choices. I'll make a note to update the documentation.

[Anonymous User]

James, thank you for the update and I appreciate the feedback.

[ChristopherCounsell]

Hi @JamesTedrick ,
Was the documentation updated? It is indicating that the name column in the choices sheet should not contain special characters. There doesn't appear to be any Excel warnings/errors on the survey file.

Should this refer to the list_name column? Can special characters/spaces be placed in the choice sheet 'name' column? I recall seeing some issues manifest from this but can't find any further documentation to confirm or back this up.

Cheers

[AnnaScholl]

status?

[ChristopherCounsell]

https://community.esri.com/t5/arcgis-survey123-ideas/add-data-validation-for-special-characters-in/i...

In my experience there was at least 2 or 3 issues tied to choice name value handling when they have special characters, within the Survey123 platform. There were also more issues when the values move to the rest of ArcGIS e.g. file geodatabase domain lists. I'm not confident that @JamesTedrick is correct in the documentation should be revised. Based on all of our testing, no, Survey123 and XLSForms are mostly fine when it comes to the data requirements for this list. However I think the documentation is correct and that it's better practice to have database friendly values in this list. Either way, I'd like this cleared up. Would suggest voting for this idea:

https://community.esri.com/t5/arcgis-survey123-ideas/add-data-validation-for-special-characters-in/i...

[fklotz]

@ChristopherCounsell could you elaborate on the issues you have run into with special characters in the choice name value both within Survey123 and in file geodatabase domains?

I've always felt that the statement in the documentation regarding special characters in the name column of Survey123 choice lists did not make sense and was incorrect. I've not run into issues so far with special characters in Survey123 choice lists nor within domains in file geodatabases, enterprise geodatabases or in ArcGIS Online hosted feature layers. However, I'm interested in your expertise, as I'm concerned that I might not have faced issues yet because I haven't used certain functionalities that could potentially cause problems in the future. 

@JamesTedrick in 2018, you mentioned that there were no issues with special characters in the name column for Survey123 choice lists and that the documentation would be updated. Was the documentation not updated because there is actually an issue with using special characters in the name column of choice lists?

[ChristopherCounsell]

The issues were from when I worked in tech support so I don't have them specifically at hand. I recall the users had an issue with choice lists and it was resolved when they removed special characters. 

Survey123 has come a long way so maybe it's less an issue than when they wrote this documentation.

https://doc.arcgis.com/en/survey123/desktop/create-surveys/quickreferencecreatesurveys.htm#ESRI_SECT...

However, imagine you have an external choice list. A CSV. And you have choices with commas. You can imagine that at some point - within the survey123 ecosystem or outside of it - there may be an issue. It's similar to the 31 field name limit. Survey123 and ArcGIS online can handle it, but other databases can't. So they recommend not having them long.

There'll be discussion around domain values with more examples e.g.

https://community.esri.com/t5/arcgis-pro-questions/best-practices-with-using-domains/td-p/1379623

A lot of survey123 can work totally fine, until it doesn't. It's more a developer tool. You don't always get immediate feedback. Best practice isn't at the forefront. But for me, there are issues with commas in csvs, special characters in domain values, and the documentation for survey123 still says don't put special characters in the choice name column. So there's no green light to say this an ok practice. 

If it works for you don't worry about it too much. Especially if you can create the value in your destination portal. Just test it, in all intended contexts. Survey123. Dashboard exports. ArcGIS pro file geodatabase. Your enterprise geodatabase.

[fklotz]

@ChristopherCounsell Thanks for taking the time to respond!  Point taken on external selects with csv and commas if folks are building them without properly double quoting any values with commas, line feeds, etc. as per RFC 4180.

This statement of yours is very true "A lot of survey123 can work totally fine, until it doesn't."!  

One area where folks could have issues with spaces and special characters is if they need to URL encode them for any reason, such as opening a Field Map from the Survey. A few years back we had a map that opened a survey that re-opened the map to add a new feature based on data in the survey. If we didn't ensure the URL was encoded and used spaces or special characters everything in the URL after those characters was dropped (if I recall correctly). However, after learning the proper approach, we had no issues.