I would like my app to support two different roles: Admin and Staff.
Because I use a lot of user-specific columns, I would prefer to keep only one email per user account. Otherwise I would have to create another Row Owner email and duplicate many parts of my setup.
My goal is simply to prevent Staff users from accessing or editing some numeric input fields in the layout, while Admin users can access everything.
Is there a way in Glide to assign two possible roles (Admin / Staff) to a single user account using the same email, and then control visibility or editing permissions based on that role?
Each user will have either the Admin or Staff role, but with an identical email address
I’m building a Glide app for a restaurant kitchen (menu, recipes, etc.).
For each customer (restaurant), I create a customer-specific menu (items, prices, settings). The app is used by both:
the Owner/Admin (full access)
the Staff (restricted access)
My problem: I would like the Owner and the Staff of the same restaurant to use the same Glide user account (same email address), but with different permissions depending on whether they are acting as Admin or Staff.
If I create a second user (different email) for the Staff, I would have to duplicate/reconfigure everything again (menu, prices, setup), because many parts of my app rely on user-specific data / Row Owners.
Is there any way in Glide to:
have two roles (Admin and Staff) under one email/user, or
switch role inside the app while keeping the same underlying user data,
oh, so you have multiple users sharing the same login?
I have to tell you that is almost certainly a violation of Glides Terms of Use.
Every user of the App that signs in should have their own distinct email address. If you follow that rule, then your problem goes away.
Distinct email addresses and roles like Darren suggested, and not using user-specific columns, you only use it when you need multiple users to interact with the same cell in your database.
I agree with Thinh and Darren. Somehow I think you’re making things more complicated that necessary.
People have email addresses. An email address is (usually) associated to a person. One person = one user = one email address.
You could say that sometimes companies might use a generic email address to make things simpler internally (limiting licensing costs, employee turnover, …). For example accoutant@company.com or accounting@company.com so that anybody from the accounting team can sign in to the accounting software: it’s as if the accounting team were one person. Fine.
Glide considerations aside for a moment, you are expecting that one single email address be seen as multiple people with different admin rights? I don’t see how this makes any sense.
All of this is digital, I guess anything can be done, but I’m not convinced that what can be done should be done. I think you need to go back to the drawing board to get a clearer understanding of your users and their permissions.
The houses exist only once in the Houses table
They are simply linked to different users
The question is about the structure
If I create a new user (agent2), I don’t want to duplicate all the houses again for this user. The houses should remain single records in the Houses table
Instead, I want multiple users to be able to access the same houses, possibly with different permissions
So my question is:
What is the correct way in Glide to structure this so that
• houses exist only once in the Houses table
• multiple users can access the same houses
• without duplicating the data for each user?
Create an array type column in your Houses table (I’d recommend Multiple Texts type)
Fill this column with an array of UserIDs (or emails)
For example, for House 3, you’d have ["agent1@email", "agent2@email"]
When presenting a list of Houses in a Collection, apply a filter: “where array column contains signed in users email”
This will ensure that each agent only sees those houses that are assigned to them.
Note that this isn’t the most secure method, but I suspect it’s perfectly fine for your use case.
If you wanted it to be 100% secure, then you’d need to assign roles to agents and use those roles as row owners in the houses table.
