Nova Impersonate Laravel Package

Product Decisions This Supports

• Support tooling roadmap: "log in as the user" vs. a custom internal console. The core decision this package informs is whether impersonation lives inside the admin panel you already run (Nova) or becomes a bespoke support tool. Shipping it as a Nova field keeps the capability where your ops team already works and avoids funding a separate internal product.
• Build vs. buy for a small, high-leverage internal feature. The underlying mechanic is trivial to implement, but the value here is the plumbing you don't write: the Nova field UI, the redirect into an authenticated session, the original-admin session restore, and the "stop impersonating" path. That is roughly a sprint of unglamorous work traded for a composer require and a policy gate.
• Prioritization signal for support/CSAT work. Impersonation is a cheap lever on time-to-resolution and "cannot reproduce" ticket volume. If support is a roadmap theme this quarter, this is a low-effort item that shows measurable impact without touching the customer-facing product.
• Concrete use cases to evaluate against your backlog:
  • Reproducing user-reported bugs with the exact account state, plan tier, and permissions.
  • Verifying role/entitlement logic (paywalls, feature flags, tenant scoping) without seeding test accounts.
  • QA of new features across real user segments before/after release.
  • Sales and CS demos using a real account rather than a synthetic one.
  • Account-recovery triage and support for users locked out by a bad permission state.
• Deciding whether to expose "view as" to customers. This package is strictly admin-side. If you're weighing a customer-facing "preview my storefront/dashboard as a teammate" feature, treat that as a separate product decision with its own permission model — do not let this package's existence imply the customer-facing version is nearly free.
• Instrumenting support pain as product signal. Impersonation events are a proxy for where users get stuck. Logging which accounts get impersonated, and why, turns a support convenience into a backlog input.

When to Consider This Package

Adopt when:

• You already run Laravel Nova. This is a Nova field with no standalone value; without a Nova license and an admin panel, there is nothing to evaluate.
• You have a real support/CS/QA function whose bottleneck is seeing what the user sees, not reading logs.
• You can enforce authorization in code — a Nova policy or Gate restricting the field to a super-admin or support role — and you already (or can quickly) write an audit record on impersonation start/stop.
• Your compliance posture tolerates admin-initiated session takeover in production, with a documented process and a break-glass reviewer.
• You are on (or planning) a current Laravel line — v2.2.0 adds Laravel 12 support, so the package is compatible with the current framework release rather than pinning you to an older major.
• You are a small team optimizing for shipped-in-a-day over bespoke.

Look elsewhere when:

• You are not on Nova. Use a general-purpose impersonation package (e.g. lab404/laravel-impersonate) or custom middleware with a signed, short-lived takeover token.
• You operate under SOC 2 / HIPAA / PCI scrutiny. This package gives you the mechanism, not the governance: no approval workflow, no immutable audit trail, no session recording, no automatic expiry policy. You will build those around it regardless — at which point a purpose-built internal support console may be the better investment.
• Impersonation is needed outside the web admin — API clients, mobile, CLI, background jobs, or per-tenant scoped access that Nova's global admin model doesn't express.
• You need SSO/OIDC identity fidelity (impersonating through an IdP-asserted session) or customer-facing "view as" semantics.
• Your only need is debugging. Telescope, structured logs, and session replay are cheaper and carry less risk.
• Bus factor matters. Single-maintainer, ~234 stars, zero tracked dependents, and a low opportunity score all point to a narrow niche. The v2.2.0 release is a narrow compatibility patch (a single Laravel 12 support PR) rather than evidence of a growing contributor base — it confirms the maintainer is responsive, not that the project is de-risked. If you adopt, plan to vendor or fork — the code is small enough that this is a realistic exit.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed admin feature that lets support staff sign in as a customer to see exactly what that customer sees. It attacks a specific, expensive category of support cost — the tickets that bounce between the customer and the team because nobody can reproduce the problem — and it does so without a new tool, a new vendor, or a new line item. The mechanism is commodity; the reason to buy rather than build is speed and the fact that it slots into the admin panel we already operate. It ships behind an access policy and emits an audit event on every use, so the risk is bounded and reviewable.

To engineering: It's a Laravel Nova field — a composer require, a field declaration on the User resource, and a gate. The package handles session swap and restore; our work is the two things it deliberately doesn't do: authorization (restrict to a named support role, not all Nova users) and audit logging (who impersonated whom, when, and why, written somewhere durable and outside the impersonated session). v2.2.0 is a single-purpose compatibility release adding Laravel 12 support — no breaking changes, no new surface area, so it's a safe bump and it keeps us on the current framework upgrade path. Adoption remains light, so assume we own it: keep the integration behind one small adapter class so we can swap in an in-house implementation or a fork if maintenance stops. Do not roll it out to production until the gate and the audit trail are merged — those are the acceptance criteria, not follow-ups.