I’m not sure there is a simple solution to this. You could try and do both add/edit on a single details screen, and use visibility to hide/show things as appropriate. But I’ve never attempted that, and I can imagine it would get awfully messy. So much cleaner to keep them separate, I think. Yeah there is a bit of duplication of effort involved, but copy/paste is your friend 
Hidden tabs isn’t an option. Once you hide a tab, it can’t be used - it effectively doesn’t exist.
I thought so to, so I went on putting it to the test.
As you can see in the video, we can still point towards a tab even if it’s hidden, as long as the original setting of the “go to tab” was before we hid that tab. It doesn’t show the tab name after you hide it, but it still points to it. Any ideas how can this go wrong? What are the risks?
Okay, that’s new to me. Does it work the same way in a published version of the app?
I’ll be surprised if it does.
You’re right, dead on published
OK, maybe not DOP.
I moved the hidden tab to the Menu section, and now it works also on published.
I also added another action in the custom action sequence. This seems to keep the button alive once the tab goes to hiding.
Thoughts?
Update:
I took @Darren_Murphy’s advise and tweaked the logic behind the hidden tab.
Here’s the demo app again
Here’s what I did:
Thoughts? Problems? Challenges?
Remind me again what problem this solves?
Is the purpose of this to avoid a “Show New Screen”, or…?
This allows us to point towards the same exact screen from multiple directions. One usecase is to use the same screen for both add and edit. I’m sure we’ll find many other usecases for this 
:
Where are the problems/drawbacks/disadvantages? I’m sure there are many of those…
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:
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.
In our usecase, this hidden tab is pointing towards the working table for Animals, allowing us to both add and edit animals.
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.
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.
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.
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.
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?
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?
I’m far from convinced. But maybe I’m missing something. Show me a fully functional example.
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).
Not sure I understand what you mean.
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?
Its working, thanks!
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.
I succeeded. Thanks a lot!
Thanks
This is very useful, but i cannot seem to find out how to make location a required field in the new version of Glide. Any ideas?
Do you mean getting the actual location of the user using the custom form? You can write that location to a column in the custom form, and only allow submission if that column is not empty.