Based on the sources, you don't need to create another RBAC role for listing projects. Permit.io provides methods to query resource instances that users have access to through their resource-level roles. For your use case with project-level roles (project_admin, project_coordinator) , you can use resource instance roles in ReBAC (1) . When you assign a user to a specific project with a role, you're creating a resource instance role assignment (2) :

await permit.api.roleAssignments.assign({
  role: "project_admin",
  tenant: "default",
  resource_instance: `Project:${project.id}`,
  user: "<mailto:user@example.com|user@example.com>",
}) ;

To get all project instances a user is authorized for, you can use the

getUserPermissions

function (3) :

const transactionInstances = await permit.getUserPermissions(key, [tenant], [], ["Transaction"]) ;

For your projects, this would look like: • Query all Project resource instances the user has any role on • The function will return instances where the user has project_admin or project_coordinator roles • Your super_admin with tenant-level RBAC role would still have access to all projects through standard RBAC checks This approach combines RBAC (for super_admin) and ReBAC (for project-specific roles) without requiring additional roles (4) . The ReBAC model handles the project-level permissions through resource roles and relationships (1) , while RBAC handles the global super_admin access (4) .

To learn more, see the sources I considered: [[1] What is ReBAC?](https://docs.permit.io/how-to/build-policies/rebac/overview) [[2] Sync Data into your App](https://docs.permit.io/overview/sync-applications-data) [[3] Fintech / Banking Demo Application](https://docs.permit.io/modeling/mesa-verde) [[4] Role-Based Access Control (RBAC) VS. Relationship-Based Access Control (ReBAC)](https://www.permit.io/blog/rbac-vs-rebac)