Revive Laravel Package

Product Decisions This Supports

• Roadmap: "undo delete" as a first-class feature. This package turns soft deletes — which most Laravel apps already have silently in the database — into a user-visible recovery surface. That lets you ship a data-recovery capability as a scoped feature rather than a multi-sprint build.
• Build vs. buy on admin UX. The core work here is not the restore/force-delete logic (trivial in Eloquent); it is the Filament page, filtering, model registry, scoping, and the CLI backfill for records deleted before the plugin existed. Buying this is a days-not-weeks decision, and revive:discover-soft-deleted (with --dry-run and --with-scope) is the specific piece that de-risks retrofitting an existing production database.
• Support-cost reduction. "I deleted it by accident" tickets are a recurring, low-value support load in SaaS and multi-user admin panels. A self-serve recycle bin shifts recovery from an engineer with database access to the end user, and removes the temptation for support staff to run ad-hoc SQL restores.
• Segmentation decisions: who sees what. enableUserScoping() / enableTenantScoping() / showAllRecords() are not just config — they are product policy. This is the decision point for whether a tenant admin can see a departed colleague's deletions, whether cross-tenant deletion data is visible to platform staff, and how that maps to your data-processing agreements.
• Compliance and retention policy. Soft deletes plus a permanent-delete path gives you a defensible "erasure on request" workflow (GDPR/CCPA) and a bounded retention window. Note the distinction: this is not a backup or DR strategy, and it is not an audit log — it is a user-facing recovery buffer with optional state snapshots at deletion time.
• Panel topology. The plugin is registered per Filament panel, so you can ship different recycle-bin policies to a user, admin, and tenant panel from one codebase. The embeddable @livewire(\Promethys\Revive\Tables\RecycleBin::class) component supports a narrower rollout — e.g. only inside a Settings page — before committing to a nav item.
• Roadmap risk to price in: versioning tracks Filament majors (V1→v3, V2→v4, V3→v5). Every Filament upgrade becomes a dependency upgrade with a plugin in the critical admin path.

When to Consider This Package

Adopt when:

• You are already on Filament v4 or v5 and use SoftDeletes on more than a handful of models. Below that threshold, a single custom Resource is cheaper than a dependency.
• You have multi-tenant or multi-user deletion semantics that need per-scope visibility — this is where the package earns its keep over a hand-rolled page.
• You have an existing backlog of soft-deleted records you want surfaced without a one-off migration script (revive:discover-soft-deleted).
• You want the recycle bin to be opt-in per model via the Recyclable trait, so risk exposure is explicit rather than automatic across the app.
• You can pin the version and accept that Filament major upgrades require a coordinated plugin bump.

Look elsewhere / build in-house when:

• You are not on Filament — the package is a Filament plugin, full stop. The underlying concepts are re-implementable in a day.
• You need per-record authorization (e.g. "this manager may restore only their team's records"). The read-side scoping is configurable; the restore/force-delete authorization is coarser (authorize() is panel- or closure-level).
• You need audit-grade history — who changed what, immutable logs, retention attestation. Use a dedicated audit package alongside, not instead.
• You need true backup/DR guarantees. Soft deletes are not a backup; a forceDelete here is unrecoverable.
• Vendor-risk tolerance is low. 16 stars and 0 dependents is a real signal: no downstream production evidence, small maintainer base, no community backstop for bugs.

Mitigations if you adopt anyway: MIT license means you can fork and vendor it; the surface area is small and self-contained; pin the major version; write your own integration tests around restore/force-delete/scoping before relying on it in a customer-facing panel.

How to Pitch It (Stakeholders)

To executives: We already store deleted records but give users no way to get them back, so every accidental deletion becomes a support ticket or an engineer with database credentials. This package turns that hidden data into a self-serve "Recycle Bin" page in our admin panel in days rather than weeks, and it gives us a compliant permanent-deletion path for erasure requests. The cost is a small open-source dependency (MIT, forkable) that we version-pin; the risk is maintainer depth and a forced upgrade each time we move Filament majors. Recommendation: adopt for internal/admin panels first, measure ticket reduction, then expose to end users.

To engineering: It is a Filament plugin plus a Recyclable trait. You register it per panel, tag models with the trait (requires SoftDeletes — it throws otherwise), and configure scoping with enableUserScoping() / enableTenantScoping() / showAllRecords(). It ships migrations, a discovery command with --dry-run and --with-scope to backfill pre-existing records, and an embeddable Livewire table if we don't want a nav entry. Requirements for the current line are PHP 8.2+, Laravel 11+, Filament v5. Two things to own deliberately: (1) pin the major version and treat Filament upgrades as a coupled change, (2) decide explicitly whether forceDelete is available to non-admins — that is a product policy question, not a config default.