Hey everyone, I know this question was asked before but I couldn’t find an answer to my proper case. I have an app with optional sign in. Non-signed in user has access to a tab with various element, and if he signs in, he has access to the same tab but with more options. If user wants to create an account, I want that the first screen he see to be a profil set up screen to add his personal information. Difficulty: The tab for signed in user and non-signed in user must be the same. I don’t want to create two tabs with different visibility set up. in short: Non-signed in user: access to all with restricted options Signed in user who didn’t do onboarding: Access only to onboarding screen Signed in user who did onboard: Access to all with all options Any Idea how I can do that?

If you want to do it all on a single screen, organise your components into containers and apply visibility conditions to the containers.

I don’t necessarily want to do all of this one a single screen, the set up screen can be another tab but yeah having all on the same is possible too. However, it doesn’t answer to my question at all. Basically my issue doesn’t come from if I should apply visibility condition… it comes from WHAT visibility conditions I should apply precisely. In my logic the condition should apply to a non-signed in user and a signed in user who did onboard but not to a signed in user who didn’t onboard. This condition sounds a little bit tricky to me, that’s why I asked for help.

Hey Lucas! Take a look at this :point_down: [image] wave How to create Onboarding screens Flow Community Resources Hey guys! wave Pretty soon, I’ll be launching a new video and app template for all of you to create an amazing onboarding expererience in your app! Wait for it! I’m just waiting for approval from Glide :clock1:

[image] Lucas_R: WHAT visibility conditions I should apply precisely Add an OnboardedTimestamp basic date column in the the Users table. When a user finishes the onboarding, the click on the final button will write the ‘Now’ timestamp to that column and perform a ‘Go to tab’ action back to a tab of your choosing. The way I understand it, you have 3 types of users and therefore 3 visibility conditions. Set the access configuration of the application to ‘Public + Optional’. The users is a visitor (no sign-in, no onboarding done yet): No visibility condition needed The users is a signed-in user and has not yet done the onboarding: Show component when email is not empty AND OnboardedTimestamp is empty. The users is a signed-in user and has finalized onboarding (by clicking on the last button of the flow): Show component when email is not empty AND OnboardedTimestamp is not empty. These visibility conditions can be applied to components or tabs.

Hey, your proposal is interesting, sadly a condition is also applied to guests (non signed in). Ex.: show only if X is not empty will also hide it for guests. The issue I’m talking about is the complete user flow. User is a guest, then user register. At this point I need that the freshly arrived user could only see a setup screen. The rest of the tabs will be unlocked once he finish the registration. At the moment, the only way I found to execute this is to have a copy of the tab. One made for guest, one made for logged in users. My aim is to change strategy and have only one tab for both logged and guest. The condition must hide everything but the onboarding screen (or element) to a logged in non onboarded user while displaying to guest and a logged the principal tabs (only some options changes)

[image] Lucas_R: At the moment, the only way I found to execute this is to have a copy of the tab. One made for guest, one made for logged in users. My aim is to change strategy and have only one tab for both logged and guest. The condition must hide everything but the onboarding screen (or element) to a logged in non onboarded user while displaying to guest and a logged the principal tabs (only some options changes) I don’t think it really matters if you apply conditions at the component level or tab level. @Darren_Murphy suggested you apply conditions to containers, which I thinks makes a lot of sense, since this would apply visibility conditions to a group of components. I still think what I suggested is the correct direction: 3 types of users, 3 visibility conditions. Have you tried to implement to see if it works?

It won’t, the central element which is a list, should be displayed to both guest and logged in user with onboard completed. So both of users must share the same visibility conditions. Now the problem is that it’s difficult to find a visibility condition that both can share. Your solution would work if having a copy of an element with a different visibility setting would be possible. But that’s precisely what I need to avoid. I’m already using containers visibility for specific options that are only available to logged in users. Maybe my explanations aren’t clear…

Why do you need to put a condition on something that doesn’t need a condition and is visible to everyone?

It shouldn’t be visible to logged in users who didn’t onboard.

Then it would be a condition with an OR. Show when onboarding complete OR user profile email is empty.

Force Onboarding screen after sign-in

Ask for Help

Lucas_Pires December 19, 2023, 9:52pm 13

@Lucas_R check it out!

Topic		Replies	Views
App - Static Onboarding screens Ask for Help	2	506	February 9, 2023
Create a login and a sign in screen Ask for Help	1	1142	December 13, 2023
Compulsory User Sign Up Page on Entry Ask for Help	10	1281	July 14, 2020
Creating an onboarding flow using tab visibility Project Showcase	91	8320	May 10, 2023
Onboarding before sign in Ask for Help	3	371	July 10, 2021

Force Onboarding screen after sign-in

Related topics