How to temporarily store data in form before submitting it!

I have two Apps, App_1 and App_2

App_1 is set to Public and provides information about App_2.
App_1 is view-only (no edit, add, etc.) - but User can register to trial.
Upon successful Trial registration for, the user can sign in to App_2.

In App_1, Trial Form asks for the following info:

  • Company Name
  • Contact Name
  • Contact Email

Before accepting the registration form, we first confirm that provided Email doesn’t already exist in active Users list.

If provided Email exists, the App will display a message with the same and ask use for different Email.
Note: The user already filled up the form, so we don’t want him/her to re-fill everything again,
just re-edit email and save.

If provided Email doesn’t exist (a new one), then we all good so far and form will be processed forward and two things shall happen automatically:

  • Add form data as a new row into Tab=Subscribers in GS).
    I have an Arrayformula that auto-generate a subscriber_ID.

  • Add new row in Tab=Users to fill in Subsciber_ID and Email.
    And I got this covered (using two steps approach - but working to automate this using Google script)

My dilemma: How can I store a field value before user clicks on submit because if allowed to Submit, then a new line will be added but w/ duplicated email.

I can’t call a form from a form nor could figure out how to store data before submission.

I tried User specific route, but then I got stumbled with
A. This column is visible form GDE but not in GS.
B. How to increment row as two users might be submitting trial reuqest.

My head is spinning :face_with_raised_eyebrow: Pointers !!

To temporarily store data, you must do it outside the form for validation.

Have a user-specific column that holds the email. Make a relation matching that email with the column where you store the already registered emails. If the relation returns something (is not empty) then don’t show the form button for them to fill out the rest of the details you need inside the form, and vice versa.

I had a tab=Trial_Temp - where i did what you suggested exactly. The problem is how to control two users submitting emails at the same time? This means I have to create place-holder rows in this Trial_Temp. DId this already, but them how do get user 1 to row 1 and user 2 to row 2

In the form, when you take that email value using a columns component, I don’t think that’s a problem how many people are submitting at the same time, because that original column is a user-specific one?

For my booking app, I have only one row for that booking screen and almost all details filled into the sheet are taken via user-specific columns.

Hope it helps, just get back to me if you face further problems.

About “In the form, when you take that email value using a columns component”, user must click on Submit in order for Glide to see the value but then it will be too late as user submitted rest of information and I don’t want them to re-edit and submit again because the email entered is already registered.

I did have tab in GS=Trial_Temp - which has only one row with user specific column - taking Email first before asking him to open the registration form. (this is step 1). If email is new, I show the form and all good from this poiint. The problem is while user 1 is still at this step and user 2 go to the Trial section (again before opening the form) , the Email entered by user 1 will show for user 2.

Then you are not using user specific columns

Neither user will see what each other entered for an email if you are using user specific columns.

1 Like

I am for sure. (can even see the row id and all)
One tab, one row, one field called Email.
User 1 enters email, I can see it under this user specific column.
User 2 enters email, where I can see it, it’s only one row!

You have tested with 2 separate user’s or two separate devices? Can you show a screenshot of the column settings for your user specific column?

Also, you won’t necessarily see the value in the data viewer unless you are previewing as the user. However, the relation will still work correctly.

Finally, I have got it to work.
Thanks to @ThinhDinh & @Jeff_Hager , it’s all about utilizing user-specific-column correctly.

Turns it to be much simpler.