Advanced visibility & admin rights per user per community — multi-role scenario

Dear Community,

I have spent several days experimenting but cannot achieve a reliable permission/visibility setup for the following scenario:

Situation:

  • I have a table Communities (one row per community, no user info)
  • And a table User Communities (join table: each row = one user in one community, with columns Community ID, Email, Role)

Goal:

  • Only users who are admins (“Beheerder”) in a specific community can see or use certain components (like add/edit users, admin panel, etc.) for that community
  • The same user can be an admin of Community A, a member of Community B, and not linked to Community C

What I’ve tried:

  • Managing relations from Communities to User Communities
  • Lookup and Query columns for roles/emails
  • IF-THEN constructions in both tables
  • Filtering & visibility both on Communities and User Communities
  • User-specific columns (work only in row context, not for current user’s membership in arbitrary community)

Problem:

  • In Communities, I cannot check if the signed-in user is specifically an admin for that community (I can only check “is there an admin” at all)
  • Because there’s no user context in the Communities row, visibility for admin components is not reliable per user/per community
  • In User Communities (which has user context), I cannot list all members PLUS restrict admin actions reliably with row-based visibility for a different member

What I need:

  • I want per-community admin rights: the signed-in user must be able to see and manage members only if they are admin of that particular community. For all other communities, this admin UI must be hidden.
  • I want to be able to show a list (collection) of all communities, where per row (per community) only the admin for that community sees the admin actions.

Is there a best practice for this?

  • I could not make any User-Specific/IF-THEN/Lookup construction work that reliably filters/combines both user and community context — only some generic solution per user OR per community, not both together.

Desired outcome:

  • On a list or detail screen for a community, show admin buttons only if the signed-in user is admin for that community (not any other, and not if just “an admin exists”).

My tests & findings: (please skip if you know Glide’s limitations)

  • User-Specific columns do not “follow” context for a different user than the signed-in user, only for “my user”
  • Lookups from Communities into User Communities can show all roles, but not filtered specifically for the current user unless navigated via detail row of the join table
  • Filtering/visibility UI can only use main screen source or User Profile, not related tables
  • Only “row owner” (which I do apply where appropriate) offers “real” security, but does not help with per-community admin UI unless every join is a row owner and screen is always on that table

Question:

  • What is Glide’s recommended method for true per-user, per-community admin rights and visibility? Is it possible, without Google Sheet scripting, computed columns outside Glide, or enterprise features?
  • If not, will Glide add support for “filtered lookup per user context” in the near future?

Thank you so much in advance for any working setup, workaround or example — or confirmation that this is a current platform limitation.

Kind regards,
Suzanne
OuderConnect

If you construct the User Communities table correctly, you can have a Query in the Communities table to the User Communities table, filter by:

Community ID equals this row > rowID
Email equals to signed-in user’s email

Then make sure it match only one row, and lookup to retrieve the Role.

You can build on that lookup Role for permission/visibility.

May sound like a problem you are mentioning User-Specific here. The relevant flow should not include user-specific columns.