Can anyone recommend a tutorial or tips for how to do this?
Let’s say, we want to notify a specific user each time a comment is received/a form is submitted.
Would it be safe for me to do a Lookup for the user’s email (assuming it’s in the Users sheet and not otherwise accessible)? If so, could I use Glide’s email tool as usual?
OR would I need to use Make/Zapier to do a lookup, matching the User ID in the public-facing sheet to the User ID in the Users sheet.
It’s safe, but it won’t work if the user that triggers the notification doesn’t have access to the receiving users User Profile row. You need to keep in mind that when row owners are applied, then unowned rows will not exist on a users device. So lookups and such simply won’t work.
Again, this wouldn’t work because you won’t have access to the UserID, for the reasons already mentioned.
Assuming that you’re using only native Glide tables, then probably your best option is to utilise a “Public” profiles table that contains a non-sensitive subset of your User Profiles, and doesn’t have row owners applied.
Have you tried creating the “Public” table as Darren suggested?
It will be a mirrored version of the Users table, with only “public” columns that can be visible to any users. Since it’s a mirrored version, any changes made on the table side should be updated on the mirrored table as well.
Then, for your use case, configure the lookups to be on the mirrored version so it has access to all rows.
Yes… hence my question about the lookup for the user’s email (which is in the User sheet and not otherwise accessible). Not otherwise accessible = in the sheet that is not public to the user. So the lookup would be in the public sheet but connected to the “private” sheet which has the row ower.
It will be a mirrored version of the Users table, with only “public” columns that can be visible to any users. Since it’s a mirrored version, any changes made on the table side should be updated on the mirrored table as well.
Then, for your use case, configure the lookups to be on the mirrored version so it has access to all rows.
Which is exactly what I was asking - so it is a safe way to do the lookup?
No, this will not work. If emails need to be accessible, then they need to be public and I’ma your public table. If you are trying to lookup an email and that email is in a table protected by row owners, then that data does not exist on the end users device. It will be as if it has never existed. It’s not accessible in any way…period.
Relations/Lookups are not some kind of special loophole that can bypass row owners. Relations/Lookups work by accessing data that is already loaded on the user’s device. So all data in your public table is loaded on the user’s device in it’s entirety. The private table will only load a signed in user’s owned data. If data is not there, then it’s not accessible.
Correct me if I’m wrong, but this is not entirely true. Firstly, you won’t be doing anything within glide if your data is behind row owners. However, Make should be able to access any and all data if it’s directly retrieving data from the Glide API or directly from another data source, such as a Google sheet. So yes I believe you can handle this with some external process. A webhook trigger from the app could work if you can at least provide Make with enough information for it you find and retrieve the correct email from the user table.
Relations/Lookups are not some kind of special loophole that can bypass row owners. Relations/Lookups work by accessing data that is already loaded on the user’s device. So all data in your public table is loaded on the user’s device in it’s entirety. The private table will only load a signed in user’s owned data. If data is not there, then it’s not accessible.
Thank you Jeff, this is what I was trying to understand!
Again, thank you Jeff. I’ve used Make to look up info from Glide before, so will have a go at trying to create this connection for this row owner sitch.
Yes, that’s true. But there needs to be something to provide that link. If the Public facing users table contains a RowID that’s a foreign key to the User Profile RowID, then yes.
I guess I didn’t explain this properly in my very first response
