When requesting a phone number in a form using the Phone Entry type, my user is apparently allowed to enter any random string at all.
I fully expected it to limit input to the right length, and to digits only (and maybe parenthesis and/or hyphens).
This is a simple and standard input validation, and I was surprised it was not automatically handling this for me when I chose the Phone Entry type.
I think I must be missing some simple way to enforce this validation. I can’t find anything in the documentation.
Otherwise I don’t see the point in having a phone entry field in the first place.
Yes, that post, which I hadn’t run across (thanks for alerting me to it), does match my sentiment.
What I now find only confusing is why Glide would name something ‘Phone Entry’ when it appears to have nothing to do with actual phone numbers or their formatting.
I am equally confused by a database column type ‘Phone Number’ which also seems without validation or enforcement.
On my iPhone this doesn’t even bring up the numbers-only keypad in response. And it seems I can’t manage a workaround of allowing only digits, with a minimum and maximum length of 10.
At this point, I have chosen to forego asking users for phone number information, as I would prefer not to have it over what I see as an embarrassment, that of my app not being able to provide a simple validation.
I really feel like I must be missing something. Otherwise it would seem Glide is just naming columns and entry fields with no real functionality, and with no apparent purpose except, perhaps, convenient labeling.
Is there a possible fix for this bug planned? (If this is not a bug, what is it?)
Perhaps others in the community will share what they know about plans to add validation or other work arounds.
Once I have a valid number it is a great component that allows users to trigger (1) tap to call or (2) tap to message; with the option to configure default text for the message action.
From what I’ve experienced in the past, the different types of entry components control which keyboard is displayed and don’t really factor into any type of validation. It mostly works perfectly with Android, but I’ve seen IOS kind of do whatever it wants with keyboards, which has made it hard to control.
As a column type, it doesn’t mean a whole lot, but it did help back when screens were auto generated to place the correct component on the screen. Also the entry components used to display symbols to indicate which type of value it was.
Other than for keyboard control, the phone entry component isn’t much different than a number entry or text entry component.
Create a new Feature Request to add a mask (e.g. ###-###-####) or character filter (e.g. 1-9) to phone entry, email entry and text entry columns for validation purposes so the Community can vote on it.
I kind of like the ability to enter numbers and text (to indicate cell, home, work, etc.). On Android, at least, the phone component will easily ignore any text and only work with the numbers, so it’s helpful for adding additional info, such as additional descriptors, or extensions (with a comma to add a pause).
On IOS you can create custom labels for phone numbers. So same, but different…
But my point is that phone number validation is a bit of a slippery slope, and not as simple as the OP seems to think it is. To start with, his criteria of “digits only, fixed length of 10 digits” would exclude precisely 100% of the several hundred (perfectly valid) numbers in my phone book
Personally, I think phone number validation is a waste of time.
Honestly, I think the Number Entry component would be better with a Min validation value of 1000000000 and a Max validation value of 9999999999 (US number format), but I think it still gets hairy if you start to include dashes.
People like to write phone numbers deferent ways… so i would recomend using IF column to check if entry column contains characters that you don’t like in that field and action would be show notification or disable submit button…
Is not hard to do
Thank you, all, for your thoughts and suggestions. In response to several replies at once, let me clarify…
The ability to click on a stored phone number and trigger a device to start a call is great, but for now requires the data to be correctly formatted (which to me means manually curating it).
I understand validation is complex, with regex or otherwise, but the issue is more easily solved by most sites nowadays by front-end data input restrictions.
When was the last time you saw a website with a phone number field where you could even possibly enter an invalid number?
I think this is most often done with Javascript, automatically includes parens and dashes, handles US and foreign numbers, and doesn’t require using a mouse click or tab key to jump between sections of the number.
That is the functionality I expected with Glide’s ‘Phone Entry’ field.
I will file a bug/request with Glide mentioning such details.
Good tip – I agree. That’s the best workaround I have come up with so far. It could at least force a user to put in 10 digit number that doesn’t start with 0 (good for US users only but that’s fine for now).
