Paywall Request 🔑

Hi folks !

Imagined flow :

  1. User buy items
  2. Payment accepted
  3. User access form in app
  4. Results form instantly display on app or send to validation

Case of use, jobs board, object selling, …

Is it already possible ? Some tricks to do that without external form ? Thanks.

1 Like

Since you can pass an SKU to the Buy Button and that SKU along with the logged in users email is saved to a sheet as part of the Buy Button / Stripe process, you could write a script to scan through that sheet, see the payment for said SKU and then create a row in another sheet, with the users email and what product they purchased. You could then have a linked list attached to the users details that is set to “Filter rows by signed-in user”.

So yes it can be done now with some scripting.


Thank you very much George for this solution! Unfortunately this is not appropriate in my case because, by default, my app is in “public” mode, so I can not filter by user. I want there to be as little friction as possible.

I hope that the team can develop this function that can be very interesting for all non-physical purchases.

I am waiting with a lot of hope!

If the user doesn’t authenticate, how would you expect their purchase to restore in case they delete the app and come back, or browser data is lost, or they switch phones? Would only paying users have to authenticate?

I think I understand you @Mark, but by authenticate do you mean log in to the app using one of the email/pin methods?

I’m asking which method @JulienPIAO would prefer, whether it’s currently implemented in Glide or not.

1 Like

This cannot be done and is not a glide issue.
The logic is contradictory.

It’s either you have an app that allows everyone to see everything (public), that’s the easy one

Or you have an app that allows some people to see some things (public with email or whitelist)

You can’t have both at the same time.
Once you settle on using email filtering your solution will emerge.

currently, my app is in public mode so anyone can use it without friction. But on the other hand, if users want to use chat, comment or fav (or even buy?) on my app they need to identify themselves. And i like this type of flow.

If i want to use, “user filtering feature” needs me to switch to email mode whitelist or email connection, and so, request user email before use the app.

My lovely flow :arrow_heading_down:

  1. User buy an immaterial item
  2. He submit his email adress and request infos
  3. Payment accepted
  4. Access to a new screen with the thing’s he buy (special link, form for adding item in app,etc…)

I think it could be a great feature.

Hope you understand me and i’m so sorry for my poor english.

I think the way you are setting this up could make it more work for your self and your end user.

if i’s simplicity you want, use a webpage like to sell your app and then once they purchase pull their email into the app as a user.

this way you can just build a pro app with filtering and separate the two things. Unpaid public or paid with filter.

final option is to build 2 separate glide app. one public and one filtered. But again you can’t have the same app be both private and public at the same time.


the final need feature is
Pay to add an item to an item list

Ex: Restaurant could pay to add his restaurant to city guide restaurant’s list.

I think I get it now.
On a public app, two things require a sort of login via email. One is posting a comment, the other is when a user buys something via a Buy Button. At that point there is a cookie written that identifies the specific user, even though the app is Public. However because the app is public the option to filter by user is not enabled because Glide sees that it is a Public app.

@Mark If there was a Sign-In type of “Public with optional email/pin” under app settings, that would solve this problem and maybe others could use it. If the user was not signed in, they would be assigned an invalid email by the Glide engine. Something like “@@@@”. Then all the places in Glide that have the “Filter rows by signed-in user” would be turned on for this new hybrid sign-in type. You would have to add a Button action that triggered this kind of optional sign-in.

I’m sure this is easier said than done but that is my thought.


My analogy
A website is like a picture of a car
An app is the actual car
a person’s email is the key to drive the car.

If you build a public app is like give individuals a picture of a car and telling them to drive it, without a key.

When I just started app building, I deliberated with this choice hoping to get the best of both worlds. But then I realized that there is no such thing as a public app.

IF an app is a so-called Public app, then it would just simply be a website.
And the same if a website asked you to log in and filters your info based on your identity it would no longer just be a website but now become a web app. search engine is a public website, but if you want Chrome to remember your password and gain access to gmail you have to use google web apps. You can’t have access to any web-app anywhere on the internet without signing in, because that’s what an app is.

An app by definition gives unique content to users. So what you are trying to do is use an app builder to build a website.

A suggestion is to use google sites, google form, or some other free and ease landing page to sell whatever you are selling, capture the individual’s email, and then at that point, you can give them access to the pro version of your app.

or you can build a public version of your app call it demo, and when they complete a purchase (you can capture their email and shoot them a link to the full filtered version of your other app.)

This is the same way the Play store works. Most demo apps are different from the full apps and you would have to download the full app after purchase.

You have a few apps that you can unlock full version but even those app require email login to know who you are in order to give you unique access.

1 Like

I’ll argue these points a little bit. I think the Amazon Shopping app is a fantastic example. You can use the app all you want without logging in, add things to your cart and so on. It gets customers involved in the app, and let’s them view the products. If they like what they see, then they can commit to creating an account and handing over their credit card info. In effect, the Amazon app is still tracking my device with cookies, which allows me to use a kind of filtered list…(the shopping cart). I don’t see a cart filled with all unregistered users items. I only see my items even though I haven’t logged in yet. Also, Amazon does not make me download a second app to complete my purchase which may cause many people to give up and leave. The Amazon example is a bit extreme, but I think it’s fair to want to allow access to public parts of an app for unregistered users. I’m not saying we should necessarily allow unregistered users to add items to a per user filtered list, or any edit capability for that matter. Maybe any add/edit screen that uses the Email Special Value, would then require login before use, much like how chat works. When using a filtered per user list, I think it’s reasonable to not force the developer to have to show all other user’s private list items as the only way to make the app publicly accessible.
Why not turn on per user filtering in glide? If you haven’t logged in yet with an email that matches the filtered list, you just won’t see anything, but at least the unregistered user is engaged in the app and can still see other areas of the app that aren’t filtered per user. I can see where some may have a need for this. Many people will not pay to use an app without first knowing what they are paying for and playing with it first.

Almost everything that is needed to do this is already baked into Glide. Like @George_B said, maybe a dummy email or some unique ID is assigned to unregistered devices that would cause the filtered lists to not show anything, but any other non-filtered components are freely available.

This would allow for a paywall. The user can explore the app and see the parts that don’t require per user data. If they like it, they purchase access to the rest of the features. This adds their email to a whitelist where they can then log in and see a filtered per user list. So really, I envision a Public with Whitelist option.


Ok I like the fact that you’re standing up for what you believe in and for that I’m going to help you with a workaround it’s not perfect but it will get the job done

Workaround Solution
First share your spreadsheet with another Gmail that you have and give editing privileges to your second Gmail

Give your second Gmail ownership rights so that the Glide spreadsheet is only an editor and no longer an owner
In your email whitelist sheet create a user called demo user and leave the email section blank.(or you might have to put a
Try both ways.

Switch over to your other Gmail that now owns the sheet and lock the unregistered user item line that. This will prevent anyone from editing it

Now you can add a tab in Glide called profile and set the layout to details. what will happen every unregistered user who logs into your app will be faced with this unregistered user details view but because the app is is locked from the master no one including glide can edit it. This way you can leave the edit component on for when they become registered.

Add a form button inside the profile layout for them to create a user profile. once they create a user profile, the fakeuseremail will disappear and their logged in email will Trump the data in detailed view.

You will be able to edit it then you can use relationships to give special access to the registered users for the areas that you want them to see I will send a link to show you how to do that that is the only way to do that what you’re asking to do but it has some drawbacks but at least it’ll work until you get to the real way

Easy peasy…

1 Like

Thanks for the workaround! I think this would solve the problem I have too, but seems difficult to implement.

High-level: Also looking to allow users to scroll through app without creating account until they want to add or edit.

If I’m understanding the workaround - essentially, every user is considered signed-in as a fake user until they actually register.

Thx. Glide has added the hide feature that makes this a lot easier now.

Now all you need is a user page with all the users of your app and set that page to filter by user login.

Then create a additional column references to all other sheets.

In the component view you can now make an entire component invisible based on content of any column.

So once you set a user to be admin, the admin reference component column could become visible based on that condition.

In other words, Every user has access to everywhere but is blinded by the visibility feature which check any column you choose for the trigger. Which could be a column called user level.

In glide ‘component’ is visible if user access is admin

1 Like

Glide does not provide a native way to allow a user to preview the app without logging in, then later allow the user to login to view more features or have more editing rights. @Lighted_Candle’s example would still require a login to get into the app. What he is suggesting is to use Visibility control to hide or show components based on if a user has completed a profile or been given certain rights in a user profile. A good example of this is the Finstagram template You could probably use a form button to allow the adding of data along with some sort of visibility control, but without a login, you cannot use per user data to control what a user can see. A user would have to be shown a record unique to them to be able to reference that record to other sheets. If you have a public app and have the hamburger menu visible, I think you can allow the user to login, but you may still run into some issues with controlling what the user can and cannot see. This all depends on what you are trying to accomplish with your app.

I do believe it’s a feature they could make available in the future, since chat and favorites kind of work this way, but currently I don’t believe there is not a good option. At least not an easy way that I can think of. If we were provided with a global logged in user value that we could use in filters, then this would take care of some of the issues, but probably not all of them.


Thanks so much, that’s very helpful and insightful! The Finstagram example seems to be the best option for now.

1 Like