hi team,

[opal crescent]

Hi @icy nacelle, I think seperating the organizations as tenants would makes more sense. Since whole the permission system is tenant based you can create each organization a unique tenant id. This way the schemas and all the data will be isolated according to the organizations. Does this makes sense?

Managing this with schema version might work in beginning but probably cause management and administrative overhead when things grow.

[icy nacelle]

would I then still be able to define tenant level roles?

so that they can manage multiple organizations?

[opal crescent]

got your point, so you have tenant roles which needs to interact with the below organizations.

Does creating another tenant id just for manaing this tenant schema ? kind of higher level of permissions. Such as, permissions for permission system ?

its worth to mention that almost all APIs is tenant based

So in your case f you create tenant based permissions schema, when checking the such access in your stack you should use that created tenant_id.

[icy nacelle]

interesting, thanks for the help! I will play around with this idea, I think it might work

[opal crescent]

no worries, If you have questions along the way let me know 👍

[lucid apex]

@icy nacelle we're already using the multi-tenancy of Permify and it's quite useful in separating the data

every tenant maps to a workspaces in our usecase, so single user is able to manage the data of different tenants

if your scenario includes sharing data between tenants, then alternative solution would be needed

[icy nacelle]

so there's no need to share data between tenants, but I think I found the solution, we just need dynamic roles

and I found this example on permify playground: https://play.permify.co/?s=custom-roles

which will allow the creation of dynamic roles instead of hardcoding them as relations in the schema

so with the example I provided it will end up looking something like this

entity user {}

entity tenant {
    relation assignee @role#assignee
}

entity organization {
    relation parent @tenant

    relation manage @role#assignee

    permission manage_organization = manage
}

entity role {
    relation assignee @user
}