Don’t use an Add Row action On Submit of a form. Forms already add rows natively, so adding a secondary action is redundant.
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.
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.
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).
It is possible to build custom forms in glide? The native form seem very basic.
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.
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.
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.
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?
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.
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?
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.