🔐 Secure Your Data with Row Owners and Public Profiles

:wave: Hey fellow Gliders!

Are you using Row Owners and Public Profiles to secure your user data? If not, you might accidentally expose private info. Let’s fix that.

In this important tutorial, I demonstrate how and why to enable Row Owners, create a Public Profiles table, and onboard new users in order to safely create a community app that doesn’t reference the User Profile table.

You can also reference this article in the Glide Docs:

For more info on securing your data via Roles, check out my previous post here:


As always the video is beautifully produced and particularly informative.

I’ve been going back and forth with this idea of having two user tables, one private and the other public. I have two issues with this, it’s probably just me:

  • It feels wrong to have two tables to achieve this security feature. By design in the way you do it, data is duplicated. My issue with duplication has nothing to do with the financial cost to the Glide developer, but rather why add more rows when there could be less.
  • It’s too complicated for the billion developers to do what you showed, though the security measures you showed are very important.

Would the security issue be solved if columns could be made private? (This is originally what I thought the Protected Column feature was for though was mistaken.) If made “private”, data in the cell of that column could only be seen by its associated row (like row ownership, but at the cell level and determined along a column).

I wonder how it’s done in the coding world. Two users tables as well?

Thanks again for this video, it’s very helpful.


Ya…it’s not ideal to duplicate data, but currently it’s best practice and is the recommendation from Glide. I’d also like to see “column owners” (eg. “only Admins have access to phone numbers”), but I can’t visualize how Glide would pull that off.


ya reckon?
If this is considered too complex for the average user, then I think we’re setting our bar way too low.
I’d suggest that anyone that finds this too difficult probably belongs in that larger group of 6 or 7 billion non-developers :slight_smile:

I think that’s more about the Glide architecture than it is about code vs no code.
In a typical client/server model, the client would be requesting data on demand via an authenticated API, and often there would be some sort of role-based permission model working in the back end that determines which data the client is permitted to access. Glide are currently beta testing a server side computational model. Once that becomes a thing, then these types of workarounds might no longer be necessary. For example, with server side computations and lazy loading of data - then computed columns as Row Owners become possible (in theory, at least).


Everything that can be easier should be easier, there’s a lot in Glide that could be easier. This is one of them.

I don’t disagree with that. My point was that there is nothing in Bob’s video that should be beyond the reach of anyone. There are no “magic tricks” or really advanced techniques, just standard things like tab visibility and set column values through single relations.

Please note that I’m not trying to detract from the tutorial in any way. It’s superb, as always, and will be a great reference. We can never have too many of these sorts of tutorials.


But from a user’s view, I think choosing which columns of a profile should be private feels more logical and easy than having two related tables with overlapping info and automation.


Again, I don’t disagree. And I wholeheartedly agree with @nathanaelb’s earlier comment about data duplication. It violates a basic rule of database normalisation. But, we have to work within the current constraints, and what Bob has demonstrated is the (current) best and simplest approach.

1 Like

True with all that, but you trigger me with your quote

I’d suggest that anyone that finds this too difficult probably belongs in that larger group of 6 or 7 billion non-developers :slight_smile:

1 Like

I agree 100%.

I have no background in programming so my thoughts are mostly guided by my naive intuition. Database normalization makes sense to me for instance.

The way I see Glide is that we are programming. Visually. Many aspects of traditional programming, however, do remain: for whom, the user experience, road maps, algorithmics, database design, design patterns, etc. The main part that Glide saves me from doing, I feel, is developing proficiency in the grammatical syntax of programming languages. But the algorithmic effort remains. At least that’s how I think I see it, as of now.

So I do expect that our visual programming in Glide be in line with usual practices in programming. If data duplication is a bad practice in the coding world, then I don’t want to see it in my work in Glide.

That being said, “within the current constraints” is key. As we know, the Glide team does an outstanding job at breaking down these constraints.


Love the conversation going on here. I think we all agree with everything everyone is saying:

  • there’s a need to data security and a responsibility to the developer to create the app with data security in mind
  • Glide offers data security via Row Owners
  • current best practice is to have a separate public profiles table IF you want to have a community portion of your app WITHOUT exposing user data (like emails, etc).
  • in the future, Glide can make this easier for the “1-billion developers” by allowing for server-side computation, but for now we need to develop within the walls that we’re given.

Maybe someone from the glide team wants to chime in here?


Ow no! This means with a server side computation model the price will be double or more