So I’ve tried to rationalise this from the pricing page where it mentions public users and private users. But honestly… I can’t decide which is the right way to think about it. so just gonna ask.
IF I am creating a customer portal/journal app for 500 customers where data is NOT shared. each customer can only see/access their own data entries (that they have added) onto the app. And not see anyone else’s.
What is the correct way to think about what app/page structure I should use?
a) a starter plan, where the 500 customers would count as public users? (but using login with email to filter their content view to them alone)
b) a 2xBusiness plan, where the 500 customers would count as private users? (because their content is private to them alone)??
I couldn’t find a clear definition of the use cases for private vs public users in the docs either. might be good to add in some more definition on users types (esp. for folks considering Glide for Saas applications)
Generally the only reason to make an app private is if you want to control who can and cannot access it. So if you were to go private in this case, essentially you would need to pre-register each customer as a user before they could access the app. Is that what you want?
If not, then a public app should be fine. As far as restricting access to data goes, your best bet is Row Owners. This is the recommended and most secure method.
Okay, so in that case you probably want to make it private. The thing is, your option B (2 x Business Plan) won’t really work if you want this to be a single app. Pricing is per team, so you’d need 2 separate (basically identical) apps in 2 separate teams.
It might be worth your while to reach out to Glide directly about Enterprise pricing. @Sean_Martin or @Ian might be able to advise further.
I personally cannot understand the difference if I have a logged in user that logs himself in, and then is granted access (manually through some user column flag that is set by an admin) and the “restrict access by email address” which still requires some admin or external program filling a table with authorized users. Why are those two different user types to Glide?
One of the apps I am developing I’d like to only allow access to users that have purchased something and “registered” it through a website. But they will not be purchasing it through the app. That’s the kind of customer portal that adds value to a product but doesn’t really justify the heavy spend (for a lookup-only type of app with few updates) of an enterprise plan.
The difference is that with a Private App, users cannot access the app at all (read - cannot sign in) unless they are already pre-registered. Whereas with a Public app - anyone can sign in. Sure you can restrict what they see, but you can’t stop them signing in. When building apps for private businesses, the distinction is usually very important. They don’t want every Tom, Dick & Harry signing into their app - only their employees and sometimes selected customers. So not having this distinction would in many cases be a deal breaker.
Just thinking out loud. I wonder if I could accomplish something similar with an app that is pubic with email, but in which I have a secondary table of all “registered” users, and if I let them sign in but not see any content unless they exist also in the “registered” users table.
If Glide gives us the ability to track user usage through a custom action (as @David talked about in one thread), I could use that to periodically purge unregistered and inactive users from the main user table.
That would work for me – but again, that’s a few “ifs”.
The biggest difference with a private app is that a user cannot sign in unless they are approved…meaning absolutely no data will be downloaded until they are signed in. Sure you could configure your app to hide data from view in the app, but unless you are making 100% use of Row Owners in every single table, then some data could still be accessible. For data that is shared among all or several users, you would have to make use of roles or row owner arrays (google sheets only).
It’s the difference between letting a stranger into your house with a blindfold on, compared to locking the door and keeping them outside. Just because they can’t see something after they sign in, doesn’t mean they don’t have access to at least some of the data.
For some companies, letting someone in the front door is a big no-no.
Thanks for that explanation. I think for me it would vary by product. In the case of the product I am thinking of, there would be no benefit to hack into it. The data is available in the product they purchase; this just gives them mobile access to the same data. But I see your point.
What’s the difference between this and an admin marking a user “approved” manually? Or a user that purchases “advanced features”? It’s just the means to the same goal, right? I thought that was part of the purpose of having an onboarding section of any app.
As @Jeff_Hager pointed out, the security is not there like it would be in a private app.
You’re absolutely correct. It’s basically an onboarding. I’ve used this in a couple apps of mine in the past. Glide wants your apps to be as secure as possible. So if you’re creating a private app but allowing anyone to sign in, inevitably there could be data breaches.