Hi,
Just need some pointers/guidelines. I want to create a long form that needs to be filled in by a user (loan application, bank account) in my particular case I am doing an accident claim.
Thanks for any guidance.
Interesting question. I can think of at least 2 or 3 different ways to approach this, and each has pros and cons.
But first I would ask the question: do you need to allow users to review and/or edit their responses before final submission?
For now I’ll assume that the answer is probably yes, and if that’s the case I’d suggest it will be easier to do the lot on a single screen. But, with clever use of visibility conditions you can set it up to give the appearance of it being multiple screens.
Here are a few ideas:
Either way can work, but it’s generally easier to keep all related data in a single sheet. But at the same time, you want to avoid data redundancy as much as possible. It really depends on your data.
If you choose to split into multiple sheets, then you’ll need a common attribute to link them together. Using the approach I described above, you could set a Unique Identifier into a User Specific Column at the start of the process, and then use that with a multi-step action at the end that adds a row to each sheet.
The approach I described would give you that.
Hi @Dan_San, this is clearly an interesting topic.
To illustrate what @Darren_Murphy explained, I show you what I achieved by following his guidance (nb: my “custom form” has 100 fields).
The slight complements that you’ll see in the video (depending on your use case) are:
@Darren_Murphy @AyS_0908 Thanks for the feedback brilliant community ! This is exactly what I needed. I will break it into small tasks, as there is still a lot I need to learn to get this to completion.
No problem. Don’t be shy about asking for help if you get stuck along the way.
I’ve been building an app in almost exactly the way you’ve described @Darren_Murphy , good to know it’s considered a good practice. There’s one way that I’d really love to be able to improve this, and that’s having the ability to pull the text for all of my components from a separate table, similar to how a choice component works.
Back when I started with Glide I thought it was great idea to use the first row of a table to enter the component text, but I’ve burnt myself too many times accidentally deleting it. How others use the user table to draw from I really don’t like at all.
If there’s another slick way that I’m missing, I’d love to hear it.
Edit: Somehow writing this unlocked something in my mind I didn’t consider before, or didn’t know enough about… a relation and then lookups allows me to do this. I just need to have a row added / column set first to be able to use the relation.
Thanks @Darren_Murphy greatly appreciate it. Was hoping to use me help line scarcely, but after an hour of struggling with my first attempt at using USCs i’m a little stuck.
I have created a form and add in an action_text component, I am not seeing any of my USCs in the dropdown column list BUT if do it outside of a form (in a main tab) then it works fine.
Hi, you shouldn’t start with the native Glide “form”; what Darren calls a ‘custom form’ is - using a standard button
create an ‘action’ on it.
select “show detail screen”
WOW… THANKS. I am 90% there with a basic POC, every sentence/instructions from you guys has been a rich learning experience 
. I have one issue and some points of clarifications to help me connect all the dots in my head.
“Button Bar” to go forward and back. Is there a way I can restrict the range, so user doesn’t put it out of range by keep hitting the buttons. I was trying to figure out how I can use if-then condition somewhere.
I created a new GLIDE TABLE and called it working, at creation it had four default columns highlighted in yellow. Are these important or can I delete them.
When I added my USC columns it did NOT ask me nor did it create a unique ROW ID column like it did in another sheet and as per Glide docs regarding USC 
Is this an issue ?
When I first created the form, it was greyed out and I could not use it, until I manually added in my email to the OWNER column. I understand why, but not sure if I need to create a relation with the user profile table so it works or will the owner field be self populated by Glide at time of authentication
At SUBMIT, I write my row to WORKING sheet and then I clear the fields before going back. I added an inline list for the user to be able to see/view the forms submitted. I enabled the edit option. The user can edit however, it seems to add a new row at the bottom and delete the original row. Is this correct ?
You can delete them. They are default columns.
Seems like you did this in a Glide Table. Glide Tables don’t necessarily need RowIDs to create a USC.
Do you use row owners?
An edit option should not do that. Did you add an add row action anywhere?
No. the only “add row action” I have is on the SUBMIT form on the custom form. However, when I edit as a user, it seems to be presenting me with that form with that SUBMIT button.
So can you record a video of this? Make sure you include your settings as well. Thank you.
hehe, it occurred to me at the time that you would bump into this problem, but I didn’t want to overcomplicate things for you so figured I would wait till you come back and ask about it. Yes, an if-then-else column can help with this. Let’s say you have 5 “sections” in your form, then the logic would be:
And then you actually use the if-then-else column value to control your component visibility.
Edit: don’t do that, it’s a bad™ solution and only solves half the problem. See my reply below for a better option.
As Thinhn mentioned, RowID’s aren’t required in Glide Tables. Personally, I always create one anyway out of habit. They are one of my little security blankets 
That’s the “Owner” column that Glide put there when you created the Glide Table, yes? There is nothing special about that column, it it won’t be a Row Owner column unless it make it one. I usually delete it, or rename it to use for something else. All you need is one row with some data in at least one column - it can be garbage data, just as long as there is something.
I think you might have gone off script slightly here. I assume that WORKING is not supposed to the be final destination of the data, right? Unless it is (and that’s certainly not what I was suggesting), then you should not be adding any rows to that table. In fact, this table should only ever contain a single row, with all users writing to user specific columns in the same row.
With the Add Row action tied to the submit at the end, you should be writing to the final destination sheet, or sheets, whichever the case.
And yes, as Thinh mentioned, it would be good to see a video of what you have so far. This will help visualise it and it’ll be easier to help.
hmm, just realised that this only solves half of the problem. In fact, it’s a bad solution, so don’t do that
Better to prevent it going out of range in the first place by adding conditionals in the button bar actions. So you’d need to make each of them custom actions and put the logic in there.
On the left (decrement) side for example, maybe something like:
(The “None” action isn’t available inside custom actions, so the “Open Link #” is a trick you can use to simulate one.)
The one thing I don’t like about this approach is that it can get very messy and complicated with so many components on a single screen and so many visibility conditions to manage. Although, a little birdie recently mentioned that we might have component grouping on the horizon, which would make this a lot easier to manage.
Another approach that I have used is a series of “Show New Screen → This Item” actions. This simplifies things in terms of managing components, although navigation can get a little tricky. If you have lots of steps you can wind up in a “turtles all the way down” situation and a bunch of “Go Back” actions at the end.
A variation on that approach (for this specific use case) would be to add a new row after the first step, and then have subsequent steps editing/adding to that row, or adding related rows in associated tables. I often use this approach when I have an indeterminate number of associated records that need to be added to a separate table and associated with a single “master” record. I’ll use a unique ID that’s generated at the start of the process, and hold that in a user specific column to be used with each “child” record.
Yet another approach (although maybe not appropriate in this case) is the multi-tab approach that I think you have used, and I know @Mark_Turrell uses in his Covessa apps.
So as is often the case, many different ways to skin the cat 
Hi, as a complement, an other approach that I use is creating a “1 field” Form, then leading the user to fill-in all the field in the detail screen.
Once again thanks for the taking the time to explain. I am learning a lot, its only my 3rd day on the platform. So having to re-read and re-watch the videos everyday and absorb a little more each day, but the community is awesome.
Excellent. I did NOT use the else → go to # and it seems to be working. So wanted to double check
This is my custom action. When it gets to zero the button greys out so you cant press it anymore and same for the forward. Just to ensure I followed your instructions correctly this is applied here
I thought I was going off script when I did it. I have a sheet called ACCIDENTS which is my main sheet and WORKING sheet is what you asked me to create. Initially I read it as that WORKING was going to act as like a runtime cache/memory and I would write to ACCIDENTS, but when I tried to do that with a custom action on SUBMIT I was NOT seeing the USC columns I created on the ACCIDENTS sheet, after trying various stuff and reading, I assumed that I had to work with WORKING.
This is my accident sheet (google sheet) with USC on it
This is my custom action, when using WORKING I see the USC that I can write to, after I write to the sheet I am having to clear the fields otherwise when I was going to register my second accident it was still showing the fields from the previous
Nice! I think you may have discovered some behaviour there that I wasn’t aware of, so you’ve helped me learn something
Okay, regards the rest of it, it looks like you’re building the form on top of the wrong sheet/table. From what I can see, you’re building the form on top of the Accidents sheet, but it should be on top of the Working sheet.
If you go back to my original response, it looks like you might have missed or misunderstood this step:
(Actually, that might need to be a “Show New Screen”. I blame Glide for any confusion - they’ve recently renamed a bunch of actions)
You shouldn’t need any of those user specific columns in your Accident sheet - they should all be in the Working sheet.
So the flow will be:
Thanks Darren,
I did as you instructed and it seems to be working fine now. I had to recreate the whole form once I chose “Show New Screen”
I came across one issue, when I was clearing the working sheet, I also cleared the USC counter, BUT when I went to the form the button bar (back/forward) was not appearing, changing the data in this column to anything made it appear. There are NO VISIBILITY conditions attached to this component, I resolved it by setting the value to 0 when the final submit button was clicked.
I will now continue to build in the rest of the stuff.
Instead of clearing the column through the action, just reset it to 0 through the action.
