Action trigger, validation and logic - why are logic elements seem to be at the wrong position (data)?


After playing around with glide pages, I got really excited as it seems to be a very well-made platform and easy to start my project. But then we ran into a very frustrating issue…

Validation, action triggers - and the logic in general…

Let’s say we have a form - and a basic data entry…
The client should give us his start and end date…

Now, you would expect that there would be a trigger to check if the dates are right after entering the dates…
But there is not.

And I really can’t understand why - everything is there, just not at the right places.

So, I would expect once someone has entered a date, I would have an action trigger after.

Also in the action setup, which looks great but is missing the “else”

element - let’s say on the form submit trigger we like to validate fields → if end date is lower than start date show notification “End date must be equal or higher than start date” else add values to current row.

So, my question is - is there something like this coming cause for a real online app that is needed - and we would look then for now for another platform…

Thank you,


You’re right, native Glide Forms are somewhat lacking in data validation functions.

There is some basic data validation that can done at the component level. For example, with dates you can restrict the range to before or after the current date, you can set a range on number entry, and you can set a character limit on text entry.

For anything beyond that, you really need to use a Custom Form.

Custom Forms are a bit more work, but they give you much more flexibility, especially when it comes to data validation. The big difference is that data inputs are available in the data editor immediately, so you can use them to perform calculations and relate to existing data, and provide immediate feedback to the user - before the form is submitted.

1 Like

Played more and found a little plus in the action editor…
So, that with Darren’s recommendation to use custom forms might give at least a workaround.

So this would work as an end validation for all fields, as you can add other Ifs to the else trigger. So we can verify / validate everything on the action button :slight_smile:

So now another one -
can I create action components? And where would I find them after I said save?

That wouldn’t actually work with an Add Form.
When the user submits the form, a new row is added immediately.
Any onSubmit action that you configure runs after the form is submitted, and is completely independent of the Add Row action (which happens automatically).

So as I mentioned, a custom form is your best option.

Here is an example of a Custom Form in action, with built in data validation:

Note that:

  • as soon as the user selects a Leave Type, we tell them what their available balance is
  • Start Date & End Dates are validated against each other
  • Once a valid date range is selected, the user is informed how many leave days will be deducted (accounting for weekends and public holidays)
  • The Submit button is disabled until all validation rules pass

This is the sort of stuff you can do with custom forms, that can’t be done with a native form.

Can you define what you mean by action component, an example use case perhaps?

1 Like

We actually build in glide pages - I’m not sure if there is such thing as a custom form…
Our work around we are working on is: (like a programmer would tackle this…)

List → select → details screen → custom action → copy data to submission table → open detail screen for submission table → enter and validate data → custom action copy data to row in original table.

by action component I mean the custom action option to create own actions and then we could save them and use them elsewhere - same thing would be great for page elements to gather them in a component save that component and use it at another page in the webapp

Yes, Custom Forms can be used in both Apps & Pages.
Note that Custom Forms are not an “offical” Glide thing - it’s a just a technique that many of us use when we need that extra flexibility that the native option doesn’t provide.

Yeah, that looks a lot more convoluted than it needs to be. Hate to sound like a broken record, but that can be simplified with a … you guessed it :wink:

Ah, right. Re-usable actions.
Yeah, that’s been an outstanding feature request ever since Custom Actions became a thing. Glide have indicated that we’ll eventually get it, but no idea when…

1 Like

Thanks, is there any example how to set up a custom form?

If you follow that link, you’ll find a concept app that can be copied.

Nice - thank you - had a look, basically it does exactly what we described up in our post just in one table instead of two. As we’re having a lot of fields, we think two tables would be cleaner, or is there a specific reason to do the temp fields in one table??

One small thing - should be all temp fields be user-specific? - we can’t really get the grasp out of them. If we got it right, there is no use of them in tables that needed to be edited by multiple users and therefore should be only for data protection or user-specific comments or should be all temp fields user specific?

User Specific columns are an essential feature of Custom Forms. Without them, you couldn’t have more than a single user of your App using the form at the same time - as they would be clobbering each other’s data.

This is a key difference between native forms and custom forms. With native forms, data input is held in the device memory and only committed to the underlying table once the form is submitted. But with a custom form - which is basically just a details screen with input components - all data is immediately written to the underlying table.

This means of course, that when a custom form is submitted, you need an add row action that takes the values from the User Specific columns and uses them to create a new row in the destination table.

The working table, whilst not essential, just helps to keep things a bit cleaner. It avoids polluting your main data table with a bunch of columns that don’t really need to be there. A nice side effect of using a Working table is that you can create re-usable Custom Forms. Once you’ve built your form on top of the Working Table, you can call the same form from anywhere in your App with a Show Details Screen action.

1 Like