Flexible redirect configuration when using tenants

[a21ns1g4ts]

Flexible redirect configuration when using tenants

Description

First of all, thank you for this amazing package 🙏 — it works great in most scenarios.

However, when we are working in a multi-tenant context, the redirect flow breaks.

For example:

• If we are under a tenant scope like /admin/1, after connecting or authenticating with a provider, the redirect always goes to the default Profile Page.
• This happens because the implementation always calls:

$profileRoute = route(Profile::getRouteName(panel: $this->userPanel));
// or
return redirect(Profile::getUrl());

But in tenant-based setups, we need to pass the tenant ID into the redirect, otherwise the user is taken out of their tenant scope and everything gets lost.

Expected Behavior

We should be able to configure the redirect target in a more flexible way.
For example, through something like:

FilamentCompanies::make()
    ->userPanel('admin')
    ->redirectsUsing(fn ($user, $tenant) => route('tenant.profile', ['tenant' => $tenant->id]));

This would allow developers to easily customize where the user is redirected after login, registration, or when managing connected accounts.

Why it matters

• In tenant applications, staying in the correct scope is critical.
• Without this, features like ConnectedAccountsForm or OAuthController redirect users to a non-tenant route, breaking the workflow.

Proposed Solution

Introduce a configurable callback (e.g., ->redirectsUsing()) in FilamentCompanies::make() to allow developers to define their own redirect logic.
This would replace the hardcoded Profile::getUrl() calls and make the package fully tenant-aware.

[andrewdwallo]

Thanks! Glad you like it. Why would something that's supposed to be under the context of a user have a tenant scope? A user's profile doesn't belong to a tenant, it belongs to a user.

[andrewdwallo]

You are welcome to make a PR!

[a21ns1g4ts]

I'll consider using routes outside the tenant context for now, but I must admit that our apps use different databases for each tenant, and in some cases, we'll need to use the path context to resolve the tenant. Thanks, I'll try to write a PR that's the best of both worlds. Thanks.