⁨``` definition user {} definition singleton_acme_org { relation employee: user permission administrate_customers = employee } definition customer { relation acme_root: singleton_acme_org relation member: user relation acme_admin: user // admins have to be assigned acme_admin on this org while being a member of the acme_root org. permission do_admin_stuff = acme_admin & acme_root->administrate_customers permission view = member } ```⁩

the other option I considered was making a special ⁨`acme_user`⁩ but that seems like it'd cause some complexity in checking permissions properly . Curious if there are any approaches I'm missing here

the only thing to be careful of is LRing when a user is an admin on too many orgs

the intersection you're doing guards against that to some degree - at my old company we didn't have that intersection and blew up our LRs when admins attempted to look at the app

we ended up taking an impersonation approach where an admin user would just give themselves elevated access on the org that they were working on

but what you're doing seems sane

ah i see LookupResources (ty chatgpt) yeah the scale here is on the order of hundreds so I think we should be fine from that angle. thanks @yetitwo ! just to double check, I assume there's no way to state that the relationship itself has to be on a member of the ⁨⁨`singleton_acme_org`⁩⁩ right? ie something like: ⁨⁨``` definition customer { relation acme_root: singleton_acme_org relation acme_admin: user & acme_root->employee ```⁩⁩

you can use a write precondition to check the employee relation itself