Title: Users table only works reliably for my own row — tester rows fail to hydrate/populate consistently across app
I’m building a fairly large Glide app (“Commuter Eye”) with realtime-style operational systems including:
Live Updates (alerts)
Tunnel Talk (discussion threads)
Replies
Favorites
Arrivals
GPS/location logic
Route/session state
I’ve narrowed a large number of instability issues down to what appears to be a deeper Users table / user hydration issue.
The strange part is:
MY row in the Users table works correctly and populates many computed/user-specific columns normally, while tester rows do not populate the same columns consistently (or at all).
Examples of columns that work for MY row but not reliably for testers:
Viewing Incident ID
Viewing Cluster Row ID
Selected Route ID
Nearest Stations
User Location Coordinates
Arrivals Web Embed URL
Incident Count
Favorite Routes Relation
Draft Route/Alert state
Push Alerts Enabled
Editing Profile
Various relations/lookups tied to user state
Symptoms across the app:
Replies appear on device but not in Glide editor
Glide editor shows replies that don’t appear on tester devices
User profile editing inconsistently appears
Avatars/names fail to hydrate consistently
Arrivals previously became unstable until I removed Users dependency entirely
Relations work for my row but not for testers
User-specific state appears partially initialized for testers
Important observations:
Authentication itself appears to work
Tester rows DO exist in Users
My row behaves normally across all systems
Many failures disappear when operational systems stop depending on Users
Relations and realtime-style flows become stable when I use direct row IDs/screen values instead of User Profile values
This makes me think there is some hidden issue with:
user row hydration
delayed user-specific initialization
row ownership
user-specific columns
how Glide resolves tester sessions vs editor “Viewing As”
or a corrupted/misaligned Users structure
Questions:
Has anyone seen a situation where the owner/developer row hydrates correctly but tester rows do not?
Is there a known Glide limitation with large numbers of user-specific columns?
Could certain user-specific relations/lookups silently fail for non-owner users?
Is there a known “best practice” for separating operational systems from Users-dependent systems in Glide?
Has anyone successfully stabilized a large multi-user Glide app heavily using user-specific columns/relations?
I’ve attached screenshots of the Users table and several of the affected columns.
At this point I’m trying to determine whether:
the Users architecture itself needs restructuring,
there is a hidden configuration issue,
or Glide’s user-specific hydration model simply becomes fragile at scale.
Sounds like something is fundamentally wrong with your setup. You mentioned some screen shots, but didn’t share them. These would be helpful.
A screen shot of your Users table showing column headings and a few rows of data (redact where necessary)
A screen shot of your User Profiles configuration.
One very specific example of something that isn’t working as you expect it to
Also, your repeated use of the term “hydration” is confusing. What do you actually mean by this?
I don’t understand that question.
No.
If rows are unowned, then those rows will not exist on a users device. So, yes.
If I understand the question correctly, then yes - Row Owners and Roles as Row Owners.
Yes. How many do you consider a large number?
The fact that you’re asking this question make me wonder if you might be mis-applying User Specific columns. Can you descriobe (or show) how you are using them and for what purpose?
My app currently has a Users table and authentication enabled, but there does not appear to be any explicit Users/Profile binding configuration layer in the current Glide UI beyond Access/User Data.
The app seems to be implicitly inferring Users-table resolution instead of me explicitly configuring:
Users table
identifier column
row binding
profile mapping
Could this explain why:
my owner/editor row consistently initializes and populates user-specific/runtime columns,
while tester rows only partially populate or fail to initialize the same operational state?
At this point it feels less like a relation issue and more like the app owner session is receiving privileged/internal user resolution while tester sessions are not fully binding to Users rows consistently.
Works for you, breaks for testers is the classic Row Owners footprint. If the Users table has the email column set as a Row Owner but it does not exactly match the signed-in user’s email, those rows never hydrate for anyone but you, so the app quietly comes up empty for testers with no error. User-specific columns are the other trap, they are per-device, so anything you stored in one shows for you and produced nothing for everyone else. Check that the profile is pointed at the Users table, that the owner column matches the sign-in email exactly, and move any shared data out of user-specific columns into normal ones. That combination is almost always what makes a Users table look unstable across accounts.
Not quite correct. User Specific columns are per user (as the name suggests), and not per device. So if the same user signs in from multiple devices, user specific data (for that user) will be visible in all devices.
But yes, User Specific columns should not be used where data needs to be visible to more than one user.
You are right, thanks for the correction. Per user, not per device, that is the important distinction and I had it wrong. So the same user sees their user-specific data across all of their own devices, it just is not shared to other users. Which still lands on the same practical takeaway you confirmed: do not use User Specific columns for anything that needs to be visible to more than one person, that is the trap that quietly bites. Appreciate you keeping it accurate.
