You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am experiencing an issue in Filament v5 where the tenant switcher dropdown only displays the currently active tenant, even when the getTenants() method correctly returns a collection of multiple authorized tenants.
The Setup:
My application uses a multi-level hierarchy for tenancy: Organization -> Groups -> Members.
A user belongs to an organization if they have a membership in a specific group type within that organization.
The Evidence:
Query Logic: I have implemented the getTenants() method using withoutGlobalScopes() to bypass automatic injection.
Data Proof: When I dd() the output of getTenants(), it correctly returns a Collection of 3 Organizations (IDs 4588, 9375, and 11336), as seen in my debug screenshot.
UI Behavior: Despite the collection having 3 items, the sidebar tenant switcher only shows the "Personal" (active) tenant.
URL Switching: I can manually switch tenants by changing the ID in the URL, and canAccessTenant() validates correctly. This confirms the issue is isolated to the UI rendering/filtering logic of the switcher component.
Root Cause Analysis:
The framework appears to be performing a "secondary filter" on the collection returned by getTenants(). Because I have an OrganizationResource registered in the panel, Filament automatically applies the ApplyTenantScopes logic to that resource. When the switcher attempts to render the list, it checks if the models in the collection are "allowed" by the current resource's scope. Since OrganizationResource is scoped to the tenant by default, it filters out any organization that doesn't match the current tenant_id in the session.
Steps to Reproduce:
Create a panel with multi-tenancy enabled using an Organization model.
Create an OrganizationResource for that same model within the same panel.
Implement getTenants() to return multiple organizations.
Log in and select one tenant.
Observe that the switcher now only shows the active tenant.
Attempted Fixes:
I have attempted to use withoutGlobalScopes() on the main query and inside the whereHas closures. While this fixed the SQL injection of the whereIn clause, it did not resolve the visibility issue in the switcher UI.
Proposed Solution / Workaround:
The only way to restore visibility is to explicitly disable tenant scoping on the Resource class associated with the Tenant model:
PHP
// app/Filament/Resources/OrganizationResource.php
protected static bool $isScopedToTenant = false;
Request:
Is this the intended architectural behavior when the Tenant model is also a Resource? It creates a "Catch-22" where the resource needs to be scoped for data isolation, but that same scoping breaks the framework's ability to list other available tenants in the switcher.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Package
Panel builder
Package Version
v5.0
How can we help you?
I am experiencing an issue in Filament v5 where the tenant switcher dropdown only displays the currently active tenant, even when the getTenants() method correctly returns a collection of multiple authorized tenants.
The Setup:
My application uses a multi-level hierarchy for tenancy: Organization -> Groups -> Members.
A user belongs to an organization if they have a membership in a specific group type within that organization.
The Evidence:
Query Logic: I have implemented the getTenants() method using withoutGlobalScopes() to bypass automatic injection.
Data Proof: When I dd() the output of getTenants(), it correctly returns a Collection of 3 Organizations (IDs 4588, 9375, and 11336), as seen in my debug screenshot.


UI Behavior: Despite the collection having 3 items, the sidebar tenant switcher only shows the "Personal" (active) tenant.
URL Switching: I can manually switch tenants by changing the ID in the URL, and canAccessTenant() validates correctly. This confirms the issue is isolated to the UI rendering/filtering logic of the switcher component.
Root Cause Analysis:
The framework appears to be performing a "secondary filter" on the collection returned by getTenants(). Because I have an OrganizationResource registered in the panel, Filament automatically applies the ApplyTenantScopes logic to that resource. When the switcher attempts to render the list, it checks if the models in the collection are "allowed" by the current resource's scope. Since OrganizationResource is scoped to the tenant by default, it filters out any organization that doesn't match the current tenant_id in the session.
Steps to Reproduce:
Create a panel with multi-tenancy enabled using an Organization model.
Create an OrganizationResource for that same model within the same panel.
Implement getTenants() to return multiple organizations.
Log in and select one tenant.
Observe that the switcher now only shows the active tenant.
Attempted Fixes:
I have attempted to use withoutGlobalScopes() on the main query and inside the whereHas closures. While this fixed the SQL injection of the whereIn clause, it did not resolve the visibility issue in the switcher UI.
Proposed Solution / Workaround:
The only way to restore visibility is to explicitly disable tenant scoping on the Resource class associated with the Tenant model:
PHP
// app/Filament/Resources/OrganizationResource.php
protected static bool $isScopedToTenant = false;
Request:
Is this the intended architectural behavior when the Tenant model is also a Resource? It creates a "Catch-22" where the resource needs to be scoped for data isolation, but that same scoping breaks the framework's ability to list other available tenants in the switcher.
Environment:
Filament Version: v5.x
Laravel Version: v12.x
Livewire Version: v4.x
Beta Was this translation helpful? Give feedback.
All reactions