Form Submission Conditions

[Wayne_S]

I need to submit an order form into a glide table, but I need to the form to be rejected if an order already exists with chosen date and email input from the form.

I can’t seem to do it as the form submits straight into the table without allowing me to set any conditions, and if i use an add row, it submits a second form.

Any tips on how I might have more control over data input with glide?

It would also be great if I could allow users to select date ranges, and be able to restrict date selections?

[Jeff_Hager]

@Wayne_S

if i use an add row, it submits a second form.

Don’t use an Add Row action On Submit of a form. Forms already add rows natively, so adding a secondary action is redundant.

@Wayne_S

I need to the form to be rejected if an order already exists with chosen date and email input from the form.

Are users not allowed to submit an order more than once a day? I may need more of an explaination about how these orders work. Why are users selecting a date and email as opposed to including them automatically as special value components? I would think you could prevent them from opening the form in the first place by creating a relation that joins date and email together and relating to your glide table. Only show the form button if the relation is empty.

@Wayne_S

It would also be great if I could allow users to select date ranges, and be able to restrict date selections?

Something like this would probably require a custom form so selected dates can be written to a table where you can build relations or checks to verify if a date is within a certain range. This is not possible to do in a native form.

[Wayne_S]

@Jeff_Hager

Are users not allowed to submit an order more than once a day? I may need more of an explaination about how these orders work. Why are users selecting a date and email as opposed to including them automatically as special value components? I would think you could prevent them from opening the form in the first place by creating a relation that joins date and email together and relating to your glide table. Only show the form button if the relation is empty.

They can submit as many forms as they want a day however, for this app, the logged in user will be submitting a form on behalf on someone else, and they’ll need to input that persons email address. The form has a date that the order relates to. So I do not want the person submitting the form creating duplications for that date and the input email address. Think of it as one order per email address a day max.

Once the form is submitted, is goes for approval. If they need to make changes, it is unlocked and editing is enabled and it will then need to be re-approved on change (which I already have a solution for, subject to more testing).

@Jeff_Hager

Something like this would probably require a custom form so selected dates can be written to a table where you can build relations or checks to verify if a date is within a certain range. This is not possible to do in a native form.

It is possible to build custom forms in glide? The native form seem very basic.

[Jeff_Hager]

Check out this post. A custom form is nothing more than a regular detail screen with entry components that update a row in real time…and then a button to add those values to another table. It gives us a lot more freedom for validation.

How do I create a custom form?

I’m just dropping this here so I have something to refer people to when they ask. This is a simple concept app (copyable), that demonstrates the following techniques: Building custom forms for adding and editing list items (as an alternative to the native forms provided by Glide) Preventing duplicate new entries using User Specific Columns and Relations Enforcing mandatory input items The use of visibility conditions and user specific booleans to control user flow There is nothing particula…

I also mention a technique to make a custom form reusable from multiple different screens in the same app. That’s only if you need to reuse the form in multiple places.

Auto Archiving, Sanity Check, Reusable Forms, etc

I wanted to share a few techniques that I just implemented in my app. A little background…I’m building a process in my app that will replace the email address with a template value. What it does is replace user@email.com with ARCHIVE-user@email.com. The email column is a row owner column. Once ARCHIVE is appended to the email, it becomes an unowned row and is permanently hidden from the app. I’m doing this in an effort to speed up my app by hiding data that’s more than 2 years old. Unowned…

Just be aware that the use of a custom form will count against your edit/update counts a lot more than a native form would.

[Wayne_S]

Thanks Jeff will have a look - good to know it is achievable at least. Some of your links are broken so not sure how up to date or relevant this is to pages but hopefully will get me going

[Darren_Murphy]

The Custom Form concept app is quite old, but the technique hasn’t really changed much, and applies equally to Apps and Pages.

[Wayne_S]

Thanks Darren.

Looking into the I think I might have overlooked something.

I’ve already complete one app for my own business which is a client portal, all the forms in it are not user specific, I expected that the data would be held in memory until the submit button was hit, so am now concerned that I might have issues.

Should all form fields on the backend be user specific regardless of if they are native or custom?

[Darren_Murphy]

No, the only time you need user specific columns is with a custom form.

[Wayne_S]

Good to know!

Still not to sure how I’m going to go about checking if an entry already exists on a table and then preventing a submission if it does.

I’ll need to do some kind of a live look up based on the text that is being entered or work it into an actions some how. Any idea?

Best clear my calendar for the day!

[Darren_Murphy]

You create a single relation between your user specific column (the one you want to use to check for duplicates) and the related column in the table the form writes to. If that relation is not empty, then you have a duplicate.

If you make a copy of that Custom Forms concept app, you can study it to see how it works.

[Wayne_S]

Thanks Darren - one last question, do user specific columns work when there is no logged in user and anyone can complete the form?

I also do calculations on a working table that I haven’t set up as user specific, so I guess I’ll need to rebuild this and make it user specific to avoid errors, as this will be used by numerous public, non-signed in users concurrently?

[Darren_Murphy]

Yes, that’s fine.

The only difference between signed in and non signed in users with user specific columns is that the values will persist with signed in users. So if they log out and log back in the values will still be there. But with a non signed in user, if they close the App and open it again without submitting the custom form, the previously entered values will be gone.

Other than that, they work exactly the same.