You need a (non-computed) owner column in every table. In terms of populating that, you can add the Users Email address as a Special Value when a User adds a thing.
Indeed, if a users email address was changed then you would need to update all their owned rows in all tables, otherwise they would lose access to those rows.
Is this something that’s likely to happen very often?
Okay. So it’s not that users will actually change their email address, but rather that you may want to change which users have access to certain data - yes?
If that’s the case, then the best solution will be to use Roles as Row Owners. With this, you define a Role (lets say Admin, for the sake of example), and then you can assign that role to one or more users. Then instead of adding a users email address as the row owner in your Things tables, you add the word “Admin”. Then every user with that role will have access to those rows.
If one of your Admin users changes, you simply remove the role from that user and assign it to another.
So just to understand - I could use the Client Name as a role, and assign that as a row owner. Any user with that Client name as role could see the content?
Also on this note - we have 3 apps all sharing the same data.
One for internal staff, one for clients, and one for field staff. Would you recommend building all within one app using roles and permissions to segment things off from each other? or 3 separate apps?
All use same data but apps have different workflows and data access levels
Yep, that’s exactly right, and that’s a classic use case for Roles.
Just one word of caution. If you need to assign more than one role to any user, then you won’t be able to do that with Glide tables. This is because in order to assign multiple roles, you need a non-computed array column, and there is no way to create that in a Glide Table. So you’d need to use a Google Sheet (or Excel/AirTable) for your Users table.
That’s really up to you - either way can work.
Personally I prefer the multi-app approach. This comes from experience. I started off by building one big mega-app for the company I work for. After a while it became way too big and complex, and was very difficult to maintain and manage. And it also started to bog down for the users. I’ve since split it into six separate Apps (all sharing the same data source), and it’s much easier to maintain.
But YMMV. I’d recommend at least creating a separate client app, as I’d imagine their user interface will probably be significantly different to that of your internal users.