Hey guys,
in order to reduce friction in user aquisition I would like to show the signup screen later in the flow Is there any possibility to skip the signup or put it behind the onboarding?
It all comes down to your tab visibilities. How are you currently structuring your flow? I assume it’s now once users first sign in they have to go through a Sign Up tab before seeing the main content?
@ThinhDinh Yes that´s true. First screen is the signup (see below) and pin entry field. After that user sees the onboarding. I would like to switch the order.
I’m not sure that would make sense.
I assume that as a User goes through the onboarding, you would be updating information in the User Profiles table, yes?
The problem is, if a user hasn’t yet signed in, then they will have no associated row in the User Profiles table, and so your onboarding won’t work as there will be no row to save any data to.
It’s a little bit like putting the cart before the horse 
I suppose what you could do is make your app public with no sign in, and configure User Profiles. Then you could make the first screen an onboarding screen, but you’d have to save any entered data to user specific columns in some sort of temporary table. You could then have a button with a sign-in action at the end of your onboarding process. Once the user has signed-in, you’d need another action that would take the data from the temporary table and use Set Column Values to update the associated columns in the User Profiles table. I’m not sure how well this world work, but in theory I think it should work.
3 Likes
I’m doing a similar thing as @Darren_Murphy described.
My app is public, and users can order stuff also before signing in, sure I have a button to sign in right away. If they are not signed in, I store their data (including email) into a Guest table and when they check out I create a row in the user profile table. Via integromat they get a confirmation email with the info, that at the next time they can login in and check their order…
4 Likes
Thanks @Darren_Murphy and @christoph for the information. Please have a look at my setup:
1-6 screen linked to guest table, user-specific columns (name, age, email)
7 and dashboard linked to user table
Button-Action on screen 6
- create new row in user table and pick data from guest table
- delete row in guest table? → is this necessary?
- show new screen with user table → how to display user´s profile now on screen 7? This doesn´t work right now with this setup…
And: how can user login for the next session? → do I have to build a custom login screen or can I use glide´s default one?
Assuming that in steps 1-6 all you are doing is Set Column Values, then there should be no need to delete anything. And if you are adding a row, you probably should re-think that. By the looks of it, all that is required in your Guest Table is a single row.
At this point, you should be able to have a screen sitting on top of your User Profiles table, and filter it where email is signed-in user.
Just use the standard login screen. Once the user logs in, Glide will re-attach them to the same User Profile. Note that by default, Glide will keep users signed in indefinitely on the same device.
2 Likes
@Darren_Murphy Thank you so much for the prompt answer. Everything works right now, except for one point: How can parse the values from the guest table to the user table when not creating a new row?
How many rows do you have in your Guest table?
I would have just a single row, with all columns user specific. Then you just need a single relation from there to your User Profiles table, and you can Set Column Values via that relation.
Are you using Row Owners in your User Profiles table? If yes, then you can use anything to create the relation (ie. a true value in each table), and the relation will automatically form with the correct row once the user signs in. If you’re not using row owners, then you’ll need something unique to that user in each table - their email address perhaps?
1 Like
Think I´m getting there, but still some open questions. ,-)
I´m able to set a relation.
BUT: How can I store user´s email in the guest table during the sign up. Email is stored only in the user table. So I have to common value in order to create the relation? I tried to do it with the RowId, but this also didn´t work. I see different Row IDs in both tables…
So I assume that you are not using Row Owners in your User Profiles table, right?
That makes it a bit tricky. The only way to get their email address into the Guest table would be to ask them for it. Which might seem a bit odd to the user. Also, it won’t be 100% reliable because you can never be sure that whatever they enter will be an exact match for the email address they use when they sign in.
Just thinking out aloud, here is something that might work:
- Create an extra user specific text column in your Guest table, and set that to a Unique Value when the user starts the onboarding.
- Create a Single Value column in your User Profiles table that applies that unique value to all rows.
- Then use those two columns to create the relation
The above assumes that the user specific values will be retained after the user signs in. I’m not 100% sure if that’s the case, but I think it might be. The idea is that as the user goes through the onboarding, the relation will be empty (because they have no User Profile row), but as soon as they sign in the relation will be formed.
Anyway, give that a try.
2 Likes
I seem to recall testing something along the lines of filling user specific columns and then signing in afterwards. At that point the user specific values were lost because instead of only storing the values locally when not signed in, it starts syncing with server stored user specific values, which are empty. I don’t remember the exact use case why I was trying it, but I feel like it won’t work. Also not 100% sure though.
4 Likes
yeah, my gut tells me that you might be right… going to test this for myself shortly
oooh, @Jeff_Hager it works!
Try this…
One thing I noticed is that it only works for first time users. That is, if you sign out then try again, then the USC value will revert to whatever it was the previous time you were signed in. Which makes perfect sense, of course. I guess it works for new users because there is nothing server side to sync with?
Anyway, for @Martina_G’s use case, I think this should do the trick.
1 Like
Well, kind of. This is how I tested it.
- I first entered a test 1 message without being signed in. Then I refreshed the browser. As expected, the user specific value entry was wiped out.
- Next I entered a test 2 message, followed by signing in. As you mentioned, the user specific value appears to be retained in the entry component. But, I then refreshed the browser and the user specific entry was wiped out. It’s as if it was still stored locally and not on the server, even though I was signed in.
- Finally I entered a test 3 message while still being signed in and then signed out. That wiped out the entry component as expected.
If it’s the first time a user signs in, I think it can work as long as they don’t refresh the browser, or they would have to do something like trigger an action to save those user specific values to a different set of user specific values or permanent basic columns before they get overwritten from the server. Or something would have to cause the locally stored values to sync to the server. I suppose it’s kind of working because a row in the hidden table for user specific values doesn’t have a row for that user yet. Once that hidden table row exists, then it’s always going sync with the server when a user is signed in (one shot to get it right).
1 Like
@Martina_G why would you need the email of the user in the guest table if he/she is already in the user table anyway?
I’m somehow doing it the other way round:
if a user who is not signed in (this could be a new user or a registered user who did log out) does an order I store the information first in the guest table and if everything is done in the user table.
The screen where the order button sits has only one row with user specific columns.
The guest table has one row per user and also gets a unique ID which is then also passed to the user table, hence the rows in guest and user table are permanently linked. I use a unique ID here because you might end up with 2 rows with the same email in the user table
1 Like
Hey @Darren_Murphy could you give me access to your test app that I could have a look at the backend?
@Martina_G - sorry, I thought I’d made it copyable. You should be able to copy it now.
Although, there isn’t a lot to see 
Maybe a dumb question, but how do you copy an existing app like this?
