Filament Impersonate Laravel Package

Product Decisions This Supports

• Build vs. buy on "switch user" functionality. Everything here — impersonation action, switch-back banner, authorization hooks, audit table, events — is a two-to-six week build for a mid-sized team once you account for security review, tests, and edge cases. The package turns it into a composer require plus a trait and a plugin registration. The buy decision is easy; the harder call is whether you accept a 46-star, zero-dependent dependency for an auth-adjacent surface.
• Feature bet #1 — support impersonation. A row action on the users table plus a persistent banner with Switch back replaces "share your password" and "let me screen-share." The product metrics to attach are time-to-resolution on access-dependent tickets and credential-sharing incidents (should trend to zero). Success looks like: support agents stop asking for passwords within one sprint.
• Feature bet #2 — linked accounts / privilege tiering. "Work in a low-privilege account, escalate to admin with the target's password, switch down in one click" is a product-level security posture you can put in a customer questionnaire or SOC 2 narrative: a compromised daily session cannot reach the admin account on its own. This is the most defensible roadmap item the package enables, and it's a genuine differentiator versus plain impersonation plugins.
• Feature bet #3 — developer logins. Low product value, high engineering velocity value. Gated to local by default and rendered outside the panel's control, so it's a safe default-on for dev environments. Treat it as a DX freebie, not a roadmap item.
• Compliance roadmap: an audit trail you don't have to scope. The account_switches table (actor, target, reason, panel, guard, IP, user agent) plus AccountSwitching/AccountSwitched events gives you "who accessed whose account and why" out of the box. If a customer or auditor is already asking that question, this package converts an open roadmap item into a shipped one. If they aren't asking yet, it's the cheapest way to be ready before they do.
• Pilot-then-expand, per panel. The fluent API (impersonation(), linkedAccounts(), developerLogins(), canImpersonateUsing(), canSwitchUsing()) lets you enable one capability on one internal panel, measure, then expand. That's a real de-risking lever: you can run impersonation in support without touching the linked-accounts model that changes how admins log in.
• Multi-tenant and multi-panel reality. The 4.0.4 fix for tenant-aware panels (Missing parameter: tenant on registration pages) and per-panel feature toggles mean this fits an app where different panels have different trust levels — e.g. impersonation on the internal ops panel, disabled on the customer-facing one.
• Non-goal you should state explicitly: this is not an SSO, MFA, or session-management layer. It sits inside an already-authenticated Filament panel. Don't let it get scoped into an identity roadmap conversation.

When to Consider This Package

Consider it when:

• You run a Filament 4/5 panel on Laravel 12/13, PHP 8.2+ and support, success, or engineering regularly needs to see the app as another user. This is the primary and honestly the only strong trigger.
• You have access-dependent support tickets — "I can't see the button," "my dashboard is empty," permission bugs — where the current workaround is password sharing or screen sharing.
• You want privilege tiering without building it: a small number of people hold admin, everyone else works daily in a low-privilege account, escalation is password-confirmed against the target.
• You need an access audit trail and would otherwise file a ticket for one. The schema and events exist already; wire them to your logging/SIEM and you're done.
• You're comfortable with a single-maintainer, MIT, pre-1.0-in-spirit package whose 4.0 release renamed the vendor namespace and rewrote the session core. That's a red flag for churn but also evidence of active stewardship: a changelog with specific fixes, a documented upgrade guide, a Pest suite, and CI that gates on package health.

Look elsewhere or build when:

• You're not on Filament. The value is almost entirely in the Filament actions, banner, and topbar menu. On plain Laravel, lab404/laravel-impersonate (which this package explicitly dropped as a dependency) plus your own audit table is a better fit.
• You need a compliance-vetted vendor. 46 stars, 0 dependents, and a solo maintainer will not survive a procurement questionnaire. The MIT license mitigates the "what if it's abandoned" risk — you can fork it — but you should budget for that possibility explicitly.
• You need guaranteed long-term API stability. The 3.x → 4.x rename (xlite-dev/filament-impersonate → packstub/filament-account-switcher, full namespace change, config file rename, route changes) is exactly the kind of breakage that costs an afternoon. If you can't absorb that, pin the version and accept the fork cost later.
• Your identity model is already complex — SSO, SCIM, multiple guards with external IdPs, or session invalidation requirements. This plugin assumes one authenticated panel session and swaps it. It won't reconcile with a session store you don't control.
• Impersonation itself is a policy problem, not a tooling problem. If your customers contractually forbid support staff from ever acting as them, no package fixes that. Solve the policy first — you may end up wanting read-only "view as" rather than full session impersonation, which is a different (and harder) build.
• You need field-level redaction while impersonating (e.g. hide billing data from the impersonating admin). Not shipped. That's custom work on top.

How to Pitch It (Stakeholders)

For executives — one paragraph: "We can ship support impersonation, admin privilege tiering, and an access audit log in about a day instead of a quarter. The package is MIT-licensed, actively maintained, and already covers the security story we'd otherwise have to design and defend: switching up to an admin account requires that account's password, so a compromised day-to-day session can't reach admin on its own, and every switch is recorded with who, to whom, why, when, and from where. The risk is small and bounded — if the maintainer walks away, we own the source and can fork it. The bigger risk is not having this: right now our support team either can't see what customers see, or gets there by sharing passwords, and neither is a story we want to tell in a security review."

For engineering — the ask:

• composer require packstub/filament-account-switcher, run the install command, add HasLinkedAccounts to User, register AccountSwitcherPlugin on the internal panel only.
• Implement canImpersonate() / canBeImpersonated() on the model — this is the only real design work. Be conservative: super-admins only, never other super-admins, explicit deny-list for billing/owner accounts.
• Pipe the AccountSwitched event into your existing logging. Don't build a second viewer.
• Pin the major version. Read UPGRADE.md before any bump — 4.x renamed the namespace and rewrote the session core.
• Timebox: one day to a working internal pilot, excluding the authorization policy conversation, which is the part worth arguing about.

For support/success leads — what changes for them: One-click Impersonate from the users table, an always-visible banner so nobody forgets they're someone else, and a Switch back button that always works. No more "can you send me a screenshot of your screen." The audit log also means the team can point to a record when a customer asks "who looked at my account" — that turns a defensive conversation into a one-line answer.

The honest caveats to put in the same slide: Zero dependent packages and a 46-star count mean we are early adopters, not followers. That's acceptable for an internal admin tool with a fork escape hatch, and unacceptable if this ever needs to be a customer-facing, contractually-warranted capability. Decide which one it is before the pilot, not after.