Data validation best practices

I have to implement data validation on various form elements. The database is Airtable.

I haven’t seen any obvious features on that front in the product. I’ve browsed the community and found that:

  • There is a feature request: [Regex Data Validation Needed] - sorry can’t post more than 2 links().
  • There are some workaround like hiding the “Submit” button when a computed field gets out of bounds: Prevent bookings 6 months or more away (in the editor, not the sheet)
  • Here, we discuss validating input (phone numbers) with ReGex, seemingly with the “Check Text Matches” field type - I assume this again is used to hide a “Submit” button if it doesn’t match or something?: RegEx challenge (or just seems that way)
  • Or even using the “Experimental code” field type: [RegEx Test] - Sorry can’t post more than 2 links().

And then, I understand there might be more possibilities by [using custom forms] - Sorry can’t post more than 2 links() - instead of the default form element.

All in all, I see there are some possibilities here for data validation, but it quite scattered around. I think that good business applications have very good data validation, hence I want to make sure I get data validation in Glide right.

What are best practices around data validation? Since Glide doesn’t have OOTB data validation and that neither does Airtable (except for what’s accepted in different field types by default), what’s a good universal strategy to address data validation on the front-end that as easily maintainable as possible for my future peers that would work on that app?

Best you can do at this point is to create what we like to call “custom forms”

You can then use “match regex” columns on any of those user specific “form” fields to validate data. The result of those regex columns can serve as conditions as to whether the user can see a button to submit the form.

5 Likes