Filament Session Replay Laravel Package

Product Decisions This Supports

• Build vs. buy for internal support/ops tooling: this package turns "we need to see what the user saw" into a panel feature instead of a bespoke recording pipeline. It directly supports a buy/adopt decision for Filament-based admin panels, where the alternative is stitching together a JS recorder, storage, a viewer, and authorization yourself.
• Support and debugging workflow: the Sessions resource, watch page, and metrics (errors, rage clicks, vitals, device, first page, length) give support and engineering a shared triage surface. This is a customer-support efficiency feature, not a customer-facing one — size the value in reduced time-to-diagnosis and back-and-forth with users.
• Privacy/compliance roadmap: masking (maskInReplay(), blockInReplay()) and the viewSessionReplay / deleteSessionReplay gates make redaction and access control first-class. This supports a decision to ship replay only if fields handling PII are audited and marked, and to define retention/export policy up front.
• Multi-tenant and enterprise readiness: tenancy scoping, workspace columns, tenantLabelUsing(), and visibleUsing() SQL-level narrowing support a go-to-market decision for multi-workspace/agency deployments. If tenancy is on your roadmap, this is evidence the package can follow it rather than block it.
• Authorization model choice: the gate-plus-policy override (Shield-compatible) lets you decide between centralized gate control and per-model policy control. That's a security architecture decision worth making explicitly rather than by default.
• Impersonation-aware auditing: detection of Packstub's Account Switcher and impersonatorUsing() supports support-team workflows where agents act as users — valuable, but it raises a policy question (who may record and view impersonated sessions) that should be answered before rollout.
• Localization reach: EN/DE/ES/RO/RU lowers the cost of internal rollout across regions; treat additional locales as a roadmap input rather than a blocker.

When to Consider This Package

Consider it when:

• You run a Filament panel and want session replay inside the existing admin surface, using the panel's own guard, tenant, and user model — no separate viewer app.
• You have (or are planning) multi-tenant / workspace deployments and need recordings scoped per tenant, with per-workspace lists, tabs, and widgets.
• Privacy redaction is a hard requirement and you can invest in annotating sensitive fields with maskInReplay()/blockInReplay() before enabling recording.
• You need granular access control — a single gate is enough today, and you may later need policy-level delegation (Shield) or per-app deleteSessionReplay.
• Support impersonation is part of your workflow and you want recordings attributed to the impersonator.
• You want exportable evidence (JSON with events, markers, stylesheets) for escalations or incident review.

Look elsewhere or wait when:

• Stability matters more than capability right now. This is 1.0.0-beta.1; names and config may still change before 1.0. Building deep integrations or customer commitments on beta APIs carries rework risk.
• You are not on Filament, or your admin surface is custom — the value here is the panel integration; standalone replay is a different buy.
• You cannot yet answer the privacy questions: lawful basis, retention period, consent, and who may view recordings. Session replay is high-risk data; adopting before policy exists creates debt.
• You need mature, long-term-supported tooling with a versioning/SLA commitment. A first beta is not that.
• Storage/egress costs at your traffic volume are unbudgeted — recordings with DOM stylesheets and event streams grow quickly; model cost per session before piloting broadly.
• You need field-level masking guarantees across every surface and your team cannot audit all forms, tables, infolists, and layout components.

How to Pitch It (Stakeholders)

For executives: This is an internal observability capability for our Filament admin panel — it lets support and engineering watch what a user experienced without scheduling a call. The beta already covers the things that usually kill session-replay projects: PII masking, gate/policy-based access, tenant isolation, impersonation attribution, and data export. It is a beta, so the pitch is a bounded pilot, not a platform commitment: pick one panel, one team, one retention window, and measure time-to-diagnosis and support-ticket deflection. The main risks are privacy/legal sign-off and storage cost, both of which we can scope before rollout. Localization (EN/DE/ES/RO/RU) means we can extend to regional support teams without new tooling.

For engineering: The package does the unglamorous parts — recorder injection via render hook, guard/tenant/impersonator capture, SQL-level visibility filtering through visibleUsing(), policy override, and export. It is Filament-native, so it reuses our panels, auth, and tenancy instead of introducing a second admin surface. Because it is a first beta, treat the public API (record(), resource(), properties(), slug(), scopeToTenant(), config) as movable: isolate our usage behind a thin internal wrapper and pin the version. Action items before pilot: audit sensitive fields for masking/blocking, confirm storage and retention, decide gate vs. policy ownership, and verify tenancy scoping against our workspace model.