Quasi-invisible data (that eventually disappears entirely)

Hi there. Frequent support flyer Scott here again with a new problem that has me vexed.


When I first tried Glide, I thought it easiest to start with built-in Glide tables. But I quickly ran into a problem: my data were disappearing! That quickly got frustrating, and I went to try other products. But I came back to Glide to see if maybe I could apply lessons I’d learned elsewhere. Critically, this time I used Google Sheets for my data (after trying Airtable. . . but that’s another story).

That’s worked pretty well. . . until now.

Google Sheets. Two relevant tables: owners and pets. Each pet has an owner, identified in each row of the pets table with a RowID corresponding to its owner. The owner’s email address is the row owner in pets. There are no formulae on the relevant columns in Google Sheets.


Having been advised to do so by the attentive @Jeff_Hager and @Darren_Murphy (for reasons not relevant here), I arranged to set the owner at row-add time. That seems to work, as the data (the owner’s RowID, and through that, the owner’s email address) appears to be set correctly after row-add.

But even though the data appear to be there, the app acts as though it is not (as demonstrated in video 1/1). What’s more, after an unspecified amount of time (apparently unrelated to, e.g., database sync, which I’ve tested), the data disappear altogether (as explained in video 2/2).

I can reproduce the first part of the problem at will. The second part (in which the data go poof) seems to always happen eventually, but I can’t force it to happen.

Please See

Video 1/2
Video 2/2

Note: My first Loom videos ever, so. . . if it doesn’t work please let me know.



1 Like

Out of interest, why are you not just using the owner email as the linkage between the two tables?

1 Like

Yeah, I thought somebody might ask. I just don’t believe in it. I know that Glide treats email addresses as the primary join field for these things, but GUIDs are forever, and email addresses are not.

I really try not to swim upstream when it comes to established conventions on no-code platforms. But I guess the “email address is the only way to identify person-object relationships” thing was more than I wanted to concede right away. I do realize that in the end I might have to. :man_shrugging:t2:

Thanks for the reply!

1 Like

Can I also ask if the problem goes away when you remove the row owners?

1 Like

You certainly can!

And the answer is: if I do NOT set the row owner, the app works correctly (although without filtering the rows by viewer, as one would expect). As soon as I restore it, all the data weirdness immediately returns.

Does that suggest an answer for you? Because I’m completely :face_with_spiral_eyes:.


And do you see this behaviour in the published app as well as the GDE?

You can use anything for a relation, but keep in mind that emails are deeply ingrained in the user profile. Not only the rows of data that you see, but also the data that you don’t see, such a user specific column data, and anything internal to glide for user authentication. Changing an email must be done with caution, because it could break a lot of links, row ownership, or user specific values. I know that’s not ideal in a perfect database world, but that is the case here. So while your use of GUID’s is fine, just be mindful that changing an email could be an involved process. I do agree with you though, I would much rather have the ability to use GUID’s or RowID’s as Row Owners instead of emails. More so for security purposes if you have multiple owners per row.

As for your primary issue, would you be willing to publish your sample app, make it copyable, and share the link here so we can make a copy, dig into it, and play around a little bit?


I never use email addresses for relations.
I always use UserIDs for relations.
The only time I’ll ever have an email address in any table other than my User Profiles table is if it’s required to be there as a Row Owner.

I know that lots of examples you’ll see around the community (and maybe (?) even in the official Glide documentation) show relations being created using email addresses. But that doesn’t make it a good practice. I certainly don’t think it is, so I don’t do it.


I have seen issues in the GDE where row owners are either not applied immediately after a change or do not take effect at all. Both can be fixed by refreshing the browser in my experience. Additionally, this never causes an issue in a published app, hence my question.

I have also seen issues where the row owner is set via a “post submit” action, rather than as part of the submit. This can also cause issues in terms of timing, since the row may not be available to update “post submit” since the current user may not have access, due to the lack of row owner!

In summary, two points:

  • Does it work in a published app?
  • Are you setting row owner as part of submit or in a post-submit action?



I’ve never published it. This is a test app, basically, designed to isolate the variables in this problem.

Absolutely. The entire purpose of this app’s existence is to solve its own problem. :smile:

That’s interesting about email addresses—and pretty much what I was afraid of. Still, I’m not really changing email addresses; I’m just adding new rows and setting the email address automatically when I do so.

I will publish, etc., early this afternoon (PDT) when I get back to my desk. Thanks!


1 Like

Interesting! I’m going to publish it in a couple of hours (gotta run right now), so I guess we’ll see. :smile:

As to “on submit” vs. “post submit”, here’s how I’m setting it:



You shouldn’t need to set those On Submit. There are components you can add that will do the same thing when the row is added. You can just add components that retrieve values directly from the user profile and add them to your new row. On Submit is unstable if you are trying to alter values in a newly added row.


On Submit will normally work fine with Set Column provided that the newly-created row has a Row Id. However, I have seen issues (going back a while) with using On Submit to set the Row Owner, specifically because you won’t actually have access to the row after the submit since the Row Owner was not set during it. Therefore, set the Row Owner as part of the submission using one of the available “special values” or from the User Profile, depending on how the rest of your app is configured.


Scott is the 4th entry in the ‘owner’ table (user table).

Isn’t Glide going to use the first entry when it shows the TAB if he is not filtering the data for his user email?

So it would be John Tyler who is associated with the Pet screen.

I suspect if Scott were the first entry it might work. One of those Glide things…

Viva la revolución! :fist:t2: :joy:

To be long-winded about this: as a product guy, I’m a huge believer in simplifying assumptions. And I can see how, on a platform like Glide, the “email-as-userID” convention makes a lot of things easier (mostly for the Glide devs, but to some extent for the platform users as well). So I respect those kinds of decisions, and try not to swim upstream by working around them.

But there’s always a trade-off. And when the trade-off involves data visibility/ownership, I start to get a little skittish. The ultimate app I’d like to build will include a ton of PII: I’m trying to be pretty careful here.

1 Like

Here you go: https://tiny-sample-escott.glideapp.io


If it’s a special value, then it’s pulling the email of the signed in user. Not from the user table.

1 Like

I think the Row Owner will override that

1 Like

Well that seems pretty relevant! :smile:

I mean. . . why does Add Submit have an option to :zap: Set Column Values if I shouldn’t do that? What am I missing?

To be clear—in case this is relevant—I’m really only setting values in two columns that would otherwise be empty. But one of those columns is the row owner (and the problem goes away if it is not the row owner), so it’s entirely credible that that’s the problem.

I understood all the words you used, but not what they mean in that sentence. :older_man:t2: Is there a doc you can point me to? All I’m trying to do is specify that when I create this row, set the row owner column to the email address of the dude who’s doing this.

Thanks again.