Filament Account Switcher Laravel Package

Product Decisions This Supports

• Build vs. buy for “log in as user” support tooling. Impersonation is a small but non-trivial feature: session handling, authorization gates, audit concerns, and the inevitable edge cases. A free MIT plugin turns a ~1–2 sprint internal build into an afternoon integration — provided you accept the dependency risk (see below). This is the core decision this package informs.
• Support-ops efficiency roadmap. If your support workflow today is “ask the customer for a screenshot” or “have an engineer query the DB,” impersonation is a measurable lever: it shortens time-to-resolution and reduces escalations to engineering. The package makes that a near-zero-cost line item rather than a roadmap project.
• Multi-account UX as a product differentiator. The linked sub-accounts feature (with password-confirmed escalation) maps directly onto household/family plans, delegated access, agency-manages-client-orgs, and parent/child business accounts. If any of those are on your roadmap, this is a cheap way to prototype the switch-account pattern before committing to custom UX work.
• Developer/staging login ergonomics. One-click dev logins in non-production replace shared seed passwords and “which test user am I?” friction for QA and demos. Low-risk, high-convenience, scoped to staging — usually an easy yes.
• Tenant-aware admin panels. If you run Filament multi-tenancy, the v4.0.4 fix (tenant-less pages such as registration and /app/new were throwing Missing parameter: tenant) tells you the maintainer is actively handling the tenancy edge cases you’d otherwise hit yourself. It also tells you the surface is still being shaken out — budget a QA pass on any non-standard tenant routing.
• Security posture decisions. Password-confirmed escalation for sub-account switching is the kind of control that shows up in vendor security questionnaires. Treat its presence as a starting point, not a compliance answer: the package does not advertise audit logging, so “who impersonated whom, when” remains your decision to build or buy.
• Version/platform gating. It is a Filament v5 plugin. If you’re mid-upgrade or on v3/v4, this is a future bet, not a current one — pin and revisit after the Filament upgrade lands.

When to Consider This Package

Adopt when:

• You are already on Filament v5 and the switcher lives inside an admin/staff panel where the blast radius of a bad session is contained.
• Impersonation is a support and QA convenience, not a regulated access-control system with approval chains.
• You have engineering capacity to review and, if needed, fork a small package — the codebase is compact enough that a security read-through is hours, not weeks.
• You need the sub-account/escalation pattern and would otherwise defer it for lack of time.
• You want a low-commitment trial: MIT, no license negotiation, no vendor onboarding, removable in a day.

Look elsewhere (or build in-house) when:

• You are not on Filament — there is no partial-fit story here.
• You need enterprise-grade access governance: immutable audit trails, approval workflows, SIEM export, IP allowlisting, session recording, break-glass policies. Build it or buy a dedicated platform; a Filament plugin is not that.
• Supply-chain risk tolerance is low. 45 stars, 0 dependents, and a single package namespace means bus factor of one. If your policy requires a minimum adoption threshold or a second maintainer, this fails on paper today — track it, don’t ship it to production on day one.
• You only need dev logins in staging. A local-only config toggle plus seeded users may be enough; don’t take a dependency for a convenience you can write in 50 lines.
• Your tenant routing is unconventional. The tenancy bug fixed in v4.0.4 is a good signal of maturity level: the maintainer ships fast, but you should expect to be the one finding the next edge case.

Mitigations if you proceed: pin the exact version, confine the plugin to non-customer-facing panels first, wrap or gate the impersonation entry point behind your own permission check, and add your own audit log at the point of switch. Also note the release cadence — a release dated 2026-10-15 with active CI health checks suggests a maintained project, but 0 dependents means you are the early adopter, and early adopters pay in integration time.

How to Pitch It (Stakeholders)

For executives (2 minutes): Support tickets that require an engineer to reproduce a customer’s problem cost us hours per incident. This is a free, MIT-licensed add-on for our admin panel that lets support staff securely view the product as the customer — plus a password-confirmed path for switching between linked accounts, which we’d otherwise have to build ourselves. Cost: near-zero license and roughly a day of integration plus a security review. Downside risk: it’s an early-stage package (small user base), so we’re scoping it to internal staff tooling first and can remove it without customer impact. Decision requested: approve a one-sprint spike, measured by tickets resolved without engineering escalation.

For engineering (2 minutes): Filament v5 plugin, ~small surface, Pest test suite, pint lint, and a CI job that enforces the same package-health checks Filament’s directory scores on. Three capabilities: impersonation, linked sub-accounts with password-confirmed escalation, and dev logins. Known caveat: a tenant-routing fix landed in v4.0.4, so any custom tenant layout needs a QA pass. Ask: security review of the escalation flow, our own audit logging at the switch point, and version pinning. If it doesn’t hold up, the fallback is a few hundred lines in-house — the spike is cheap either way.

Metrics to instrument from day one: tickets resolved via impersonation, time-to-resolution delta for impersonated vs. non-impersonated tickets, escalations avoided, and dev-login usage in staging. Those numbers are what justify keeping or forking the dependency at the next review.