Based on the documentation, you're right that the

user.roles

attribute in ABAC conditions typically references top-level tenant roles (1) . The Mesa Verde demo shows this pattern where user sets check for top-level roles like `AccountOwner`:

{
  "allOf": [
    {
      "user.roles": {
        "array_contains": "AccountOwner"
      }
    }
  ]
}

For resource instance roles (like your

location-staff

) , these are assigned differently using the resource instance assignment pattern (2) (1) :

await permit.api.roleAssignments.assign({
  role: "Sender",
  tenant,
  resource_instance: `Transaction:${transaction.id}`,
  user,
}) ;

(1) Unfortunately, the available documentation doesn't show a direct way to reference resource instance roles within ABAC user set conditions. The ABAC conditions shown focus on user attributes and top-level roles (1) (3) . A potential workaround could be to sync a user attribute when assigning/removing the location-staff role. The documentation shows syncing user attributes is possible (1) :

await permit.api.users.update(key, { attributes: { country } })

You could potentially update a user attribute like

hasLocationStaffRole: true

when assigning any location-staff resource role, though this would require custom logic in your application. For a more robust solution that doesn't require manual attribute management, you might want to explore using the

getUserPermissions

function to query resource instances , though this would be for runtime checks rather than ABAC policy definitions. I'd recommend reaching out to Permit.io support for guidance on the best pattern for your use case, as detecting resource instance roles across all instances for ABAC conditions isn't directly documented.

To learn more, see the sources I considered: [[1] Fintech / Banking Demo Application](https://docs.permit.io/modeling/mesa-verde) [[2] Sync Data into your App](https://docs.permit.io/overview/sync-applications-data) [[3] What Is Attribute-Based Access Control (ABAC)?](https://www.permit.io/blog/what-is-abac)

Yes, ReBAC (Relationship-Based Access Control) would indeed be a better fit for your use case! ReBAC allows you to define role derivations that can automatically grant roles based on relationships between resources (1) (2) . Role Derivations for Your Use Case Role derivation allows for the dynamic assignment or inheritance of roles based on certain conditions or relationships (1) . This means a user with a role on one resource instance can automatically get another role on a related resource instance . For your scenario where location-staff should get tenant-level permissions, you can create a relationship between your location resource and a tenant/account resource, then use role derivations to automatically grant permissions (3) . How to Implement This 1. Define the Relationship First, create a relation from your location to the parent tenant/account :

await permit.api.resource_relations.create(
    "location",
    {
        "key": "account",
        "name": "Account",
        "subject_resource": "account",
    }
)

2. Create Role Derivation Then set up a role derivation so that location-staff automatically gets a role at the tenant level :

await permit.api.resource_roles.update(
    "account",
    "derived_role_name",
    {
        "granted_to": {
            "users_with_role": [
                {
                    "linked_by_relation": "account",
                    "on_resource": "location",
                    "role": "location-staff",
                },
            ],
        },
    }
)

This configuration means: "If a user has the

location-staff

role on a location, they automatically get

derived_role_name

on the account that the location belongs to" (1) . Example Implementation The Google Drive example demonstrates this pattern well (3) . In that example, users with editor role on a folder automatically get editor role on files within that folder through the parent relationship . Similarly, the banking demo shows how a user being a "Sender" of a transaction can inherit certain permissions based on relationships (4) . Benefits of This Approach • No manual role assignment/unassignment needed at the tenant level (5) • Permissions are automatically derived based on relationships (1) • Changes to location-staff roles immediately reflect in tenant permissions (5) • You can visualize these relationships in Permit's Resource Relationship Graph (1) For more detailed examples, check out: • Building ReBAC Policies • Google Drive ReBAC Example (3) • Create a ReBAC Policy Walkthrough (2)

To learn more, see the sources I considered: [[1] Building ReBAC Policies](https://docs.permit.io/how-to/build-policies/rebac/building-rebac-policies) [[2] Create a ReBAC Policy](https://docs.permit.io/overview/create-a-rebac-policy) [[3] Modeling Google Drive Permissions with ReBAC](https://docs.permit.io/modeling/google-drive) [[4] Fintech / Banking Demo Application](https://docs.permit.io/modeling/mesa-verde) [[5] Best Practices for Multi-Tenant Authorization](https://www.permit.io/blog/best-practices-for-multi-tenant-authorization)