I have a field for 'phone number' that's integer type because I want to force numbers by the end user and not allow letters. however the once the numbers are entered they appear with commas ad the values in AGOL (5,546,433) for example.
How can I remove these commas within survey123 .xls sheet? is there another parameter I am missing.
So it sounds like the issue is when you visualize the data in ArcGIS Online after publishing the survey. Am I correct in that?
If so, when you add the hosted feature service to the web map you can configure the popups such that the 1,000's separator is removed. That workflow is detailed here (easiest just to do a CTRL + F for "1,000"): Configure pop-ups—ArcGIS Online Help | ArcGIS
However, another workflow you could look into is setting the field to be a text field and then using a constraint to not allow letters. The way I set this up required a bit of creativity. In the constraint column, I used ".>1000000000" (thereby assuming that all phone numbers will be greater than this, 100-000-0000). So entering A999999999 would not work, because it is still not greater than 100-000-0000). Then to avoid confusion, you can just add something to the constraint message column for that field prompting them to enter only numbers.
Hope that helps!
I have a Survey123 form that's behaving this way as well - we're capturing zip codes and street addresses and commas are being inserted into these fields by default. I've adjusted the pop-up to preclude the commas, but I'm hoping there's a setting I can apply to ensure commas aren't added when the users are filling out the form to begin with.
FYI, the field type in XLSForm is integer.
The workflow is to export to .csv from the attribute table, and then to use a combination of Microsoft Excel and Word's mail merge function to create form letters based on the data the users are gathering; we need clean addresses without commas for mailing labels to print correctly. I realize we can always use the find and replace function once the data are in Excel, but I'm hoping to skip this step.
Have you considered using a 'text' field type in the XLSForm as opposed to integer? Please explain if this would not work for you as a solution.
It would work yes, but I see this as a workaround as opposed to treating the root issue. Street Numbers and to an extent Zip Codes are factually whole numbers, they are not text. The commas are nice to have in popups, but this should be an option the user chooses to implement, and not something placed by default and definitely not something stored in the attribute table.
Just my $0,02
Although, on first take, it does seems that an integer type field should satisfy for all ZIP Codes and Street Addresses there are some cases that must be considered. For instance, some ZIP Codes start with a leading '0' (CT, MA, MA, NJ, etc...) and lots of addresses include '1/2' in them i.e. 920 1/2 Church Street.
Due to examples like these, in fact, ZIP Codes and street addresses should be stored as strings, or 'text' type questions.