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 particularly advanced here, but it does demonstrate a few concepts that new users sometimes appear to struggle with. [image] Custom Forms Concept Update 2021-11-16: If you’re wondering what a Custom Form actually is, or when you might want to use one, then please read this: [image] Multi-step form Ask for Help A custom form is just a detail screen that’s designed to act like a form and uses entry components linked to user specific columns as the temporary placeholders for the data. Once you are done filling out the form, you can have a button with a custom action that will first have an Add Row action that will take those user specific column values and write them to a different table. You can then follow that action with a Set Column action that will clear the user specific columns so it’s ready fo… Update 2021-12-26: Concept app has been updated, to take advantage of some newer features and techniques. Changes include: A working table has been added, and is used to prevent duplicates being created on edit (this makes use of the Remove Element from Array plugin) Names are trimmed to remove extra white space Actions have been “modernised” to keep Save buttons disabled while all required criteria are not met. Update 2024-12-16: Created a new Concept App, which is available as a template.

Okay, well let’s consider the case of editing a record. When you want to edit a record using a custom form, and you’re not doing it on the current details screen, you need to ensure two things: The screen you navigate to is attached to the table that contains the record that you want to edit, and The screen that you navigate to is also attached to the correct row in the above table (or, I suppose 3. you create appropriate relations to connect you to the table/row that you want to edit) So if you’re going to navigate to another tab, how would you propose to ensure those conditions are met? It will be possible, but it won’t be simple. Conversely, if you simply do a Show New Screen → This Item, then you automatically land where you need to be. So it seems to me that the path you’re heading down is adding unnecessary complexity and creating extra work.

[image] Darren_Murphy: The screen you navigate to is attached to the table that contains the record that you want to edit In our usecase, this hidden tab is pointing towards the working table for Animals, allowing us to both add and edit animals. [image] Darren_Murphy: attached to the correct row in the above table Let’s look at this as if we’re sending data to an extremal service (Make scenario for example). Each time we send to this scenario, we make sure we provide it with the proper variables. We’ll do the same here using the “set column values” in this working table. We can add a column to indicate the “mode” in which we approach this screen, i.e. “add”, “edit”, etc. [image] Darren_Murphy: you automatically land where you need to be. We have zero control over where we land and we also must make sure we always come from the same item. Another upside I can see here is that we get a clear list of our screens (i.e. tabs) and we can edit them at will. Using the New Screen doesn’t build us a clear list of screens that we can edit outside of the direct connection to the item from which we originated. Such as list is very much available on other services such as Google’s own AppSheet. [image] Darren_Murphy: adding unnecessary complexity and creating extra work True on the one hand. On the other hand, we eradicate 100% of the chances we’ll miss something during the duplication of complex screens. I see this as a change of perspective. Instead of a single dimensional screen (serving 1-2 purposes) we get a multidimensional screen. Important to say that this workload is worth it only for super complex screens, such as adding a new client, new SKU, etc. Basically, in cases where the data integrity is critical. In these cases, we want to make sure we always follow the same exact logic when entering new data into the system. Narrowing it down. with this screen we can configure one Save button, as opposed to a dedicated Save button on each New Screen originating from the same item. This unified Save button will always check the same logic, before allowing itself to be visible/clickable.

[image] Test_Test: In our usecase, this hidden tab is pointing towards the working table for Animals, allowing us to both add and edit animals. Adding is fine, because you can add a row to any table from anywhere. But editing is different, you need to be attached to the correct table and pointed at the correct row. So are you suggesting that when the user saves an edit, you’ll do a set column values via a single relation back to the Animals table, so that the correct row is updated? Whilst that could work, again I just see it as making things more complicated than they need to be. [image] Test_Test: The tab is nested under the Menu, so technically it would be very difficult for a user to see it outside of clicking this button. If it’s in the Menu, then it’s easy enough to find. What would the behaviour be if a user navigated to it directly? [image] Test_Test: We have zero control over where we land and we also must make sure we always come from the same item. What do you mean? Of course you do. Show New Screen → This Item just opens a new screen on the current row. So you always know exactly where you are. You do realise that when you apply an action to a details screen, then it automatically applies to all items that share that same details screen, yes? [image] Test_Test: I see this as a change of perspective. Instead of a single dimensional screen (serving 1-2 purposes) we get a multidimensional screen. I’m far from convinced. But maybe I’m missing something. Show me a fully functional example.

[image] Darren_Murphy: What would the behaviour be if a user navigated to it directly? User cannot navigate to this tab, or even see it. It’s not visable unless the ShowHidden Boolean is true. That only happens when we want it to happen (and we also remove the back button via CSS). [image] Darren_Murphy: You do realise that when you apply an action to a details screen, then it automatically applies to all items that share that same details screen, yes? Not sure I understand what you mean. [image] Darren_Murphy: Whilst that could work, again I just see it as making things more complicated than they need to be. To be honest, I’m taking this approach purely due to my past experience. That was on other platforms, but I do know that somewhere, somehow, I’ll miss something if I need to duplicate things. That’s just me. I’d like to assume that most of you guys don’t have this “wonderful” experience. It’s probably just me trying to convince myself, but I do believe that the easier mindset is one screen to consolidate all additions and changes to one table.

I have tried similar logic to avoid duplicate entries when they are entered. But the app only works for a single user. If multiple users write at the same time, it mess up the data completely. How can we avoid this?

Did you see my response to your question in the other thread you created? [image]How to make user specific app for multi-user Sounds like you are using a Custom Form, yes? When using custom forms, it is very important that all of your input components are directed at user specific columns. This will prevent the issue that you’ve described.

Hello. As the other participants of this conversation, I tried to validate items being added or edited, to prevent duplicate items. The solution looks great, but I didn’t succeed to use it, because in my data table, the data is updated only after pressing the submit button. Before pressing the button, nothing is written in the data table. Do you know what is my mistake? Thanks a lot!

If you are using a custom form, then you are updating a data row as you type, so it may be the case that you are not using a custom form and you are instead using a native Glide form…or your logic to check for duplicates is in the wrong table.

How do I create a custom form?

Community Resources

Darren_Murphy July 22, 2022, 8:35am 112

Did you see my response to your question in the other thread you created?

Topic		Replies	Views
Solution to Prevent Duplicate Entry Ask for Help	85	8807	October 22, 2023
I want a duplicate check, for example, this name already exists. Ask for Help	4	653	September 13, 2024
Long Form guidelines Ask for Help	25	1445	September 4, 2021
Unique row for signup form everytime for every user Ask for Help	6	466	March 27, 2023
Multi-step form Ask for Help	19	3907	July 14, 2023

How do I create a custom form?

Related topics