A question about security through relation columns?

I am saving names and emails to a User Profile Table which uses Row Owners for security reasons. The problem is that i need to use emails on that table to send a push notification to multiple users. This doesn’t seem possible if i’m using Row Owners on the User Profile Table.
My idea is to turn off Row Owners so that i can access the email column when creating a push notification message.
Firstly: The User Profile Table data is not accessible to anyone except on a Tab that only the Admin has access to (for security reasons)
Secondly: Each user can see their own row data from within their User Profile Table (accessible from within the menu) if they are signed in. But the table is not used inside the app neither on a Tab nor in a collection etc. (obviously excepting on the Admins Tab)

Question 1: Does switching off row owners mean that everybody’s data is not secure. (Remember i’m not actually using the User Profile Table on any tabs or for collections etc, except admins tab)

Question 2: If i create a relation to the users table, does that relation then expose data to the rest of the app. (I won’t relate to any columns with sensitive data like email etc, i would relate the Row ID column to a Users ID column as opposed to relating Email to Email, not sure if that matters either?)

Question 3: I wish we could send a push notification off a hidden/virtual email address then i wouldn’t need to go through this longwinded process. Until then, does anyone know of a better way to achieve my objectives.


It makes no difference. You’ve already potentially exposed the data by removing Row Owners.

What you need is a second Public Users table:


Okay i actually have a Public Profile Table. The only sensitive info for now is their email. So instead of permanently saving their email to the Public Profile Table, i save it when users click submit then hash the email using a hash column then on submission of the same form i write the hash into the email column, so there are no actual emails on the Public Profile, which makes it useless for push notifications.

I will check this article out now, but i still can’t see how to compile a csv of emails for the push notification if the emails all come from a public table?

Will the answer to that be found in this article link that you sent? (just asking now while you’re still online)

Perhaps, but it sounds like you’re wanting to have your cake and eat it too. You can’t keep the user emails secure and at the same time allow one user to trigger a push notification to emails that they don’t have access to. It’s either one or the other.

What is the typical method that everyone uses, are emails typically regarded as public information or not as vulnerable compared to other personal data?
Do you think that by using Push Notifications we will run the risk of a data breach but since the data is only emails we’d have less issues in terms of Popia/Gdpr laws.
I am saving other more sensitive data like ID Numbers and signatures to a google sheet with protected columns so it really is just emails that i’m worried about. Alternative is to not use Push Notifications which would be a pity.

I prefer not to get into the legalities of it, because I’d be way out of my depth. But I think as App developers it’s incumbent on us to take all possible care with users data - including their email address. If you choose not to use Row Owners, then you’re taking a calculated risk with that data. The risk is probably pretty low, because the data is not easy to get at for the casual/inquisitive user - and I think Glide have made it harder than it used to be - but the data will be there on a users device and so somebody with the right skills and motivation will find it.

I think you just need to decide whether the benefit of push notifications outweighs the risk of potentially exposing user email addresses.

If this is not something that you need urgently, it might be worth your while waiting for a few months. I don’t know this for a fact, but I suspect that some of the more advanced features that Glide are planning might make it possible to do this sort of thing in a secure manner. Please don’t quote or hold me to that - it’s pure speculation.

1 Like

Okay awesome Darren, thanks for the advice. I can see some of the methods i was going to use won’t work now so you saved me a lot of time. I’m busy watching the video tutorial and i will see if there’s extra ideas there too. Have a good day/evening.

I haven’t checked but what if you use don’t collect real user email and make public just anonymous emails, because Glide still can process it?
I don’t know is works or not.

I dont believe they support push notifications to anonymous emails right now.

Have you tried adding a second row owner that is your email so only you have access to all users rows? That might work if you’re the one to trigger the push notification.

1 Like

Would that actually work? Will test this and see.
Let me know how you did that and if it works.

That would be ideal, it’s not currently possible, but hopefully soon they’ll add that feature.

Yes, @Joe_Gabriele’s suggestion would work.

1 Like

Basically as part of the onboarding process they have to enter their name and hit a button, which has a Set Column action as part of the Custom Action. The Set Column action sets my email in the Admin Email column, which has Row Owners attached. This grants me access to all User rows.


This is genius, i just tested and it seems to work. And when i view as a non admin then all other rows are dimmed out, i assume that means other rows aren’t visible to non admins.

I already set up emails to write into the Public Profile but with this i could maybe use the User Table to compile the recipient email into a csv which i’ll send to a new row in the Push Messages Table. If that works then i wouldn’t need to save emails onto the public table which i would feel is much safer.

Question: Is there a way to make the second row owners column a csv to allow multiple admins? Or is it better to create a new column for each admin, then i’d have a few more Row Owner Columns. Think that would work?

Correct. When you see rows dimmed out in the Data Editor, pretend that they don’t exist. Because that’s essentially what it means. When the User you are viewing is signs into the App, those rows won’t be loaded onto their device.

Only if your Users table is connected to a Google Sheet. Then you could create a non-computed array column. Otherwise, you’ll need multiple Row Owner columns.

What about using roles?

1 Like

Just make sure that if the objective is to protect emails, that any other table with user emails that dont have row owners will allows those protected emails to be downloaded.

Having a public profile sheet with user emails doesnt make sense. Like you said, you might be able to achieve what you need just using the user table and allowing select people access, such as Admins.

Or you can use User IDs in public profile sheet instead of emails.

Not sure about that? I use access levels, haven’t used the roles column before (i think it does the same thing though?)
If it’s like access levels then it prolly wouldn’t work because access levels use conditional visibilities to hide components or list or screens etc, but unless it’s Row Owners or Protected Columns then i believe all rows content is downloaded to the app and is vulnerable via network traffic…

FYI: by access level i mean, placing the word Admin or Editor etc into each row of the Access Level Column, then only show rows to users whose access level is Admin…

No, that’s not how Roles work.
Roles are probably a good option for your use case if you will have multiple admins.
What you would do is assign yourself the admin role (the name of the role doesn’t matter), along with any other user that needs that role. Then instead of having a separate row owner column for every admin, you just have a single one that contains the word “admin” (or whatever name you’ve used). Then every user that has been assigned that role will have access.

The below might help understand a bit more:

1 Like

Agreed, if this all works i’ll take emails off the public table.

I actually use the Public Profile Row ID as the USER ID because people don’t need to sign in to the app to get going, so the Signup form writes to the Public and Users Table at the same time.