Product Decisions This Supports
- Feature completeness for the admin panel. Soft deletes without a recovery surface are a half-built feature. This package turns "we soft-delete" into "an admin can find and restore a record in under a minute," which is what users actually expect. Use it to close that gap without writing custom Filament pages.
- Build vs. buy for a commodity capability. A central cross-model recycle bin is roughly a page, a table schema, and per-model policy wiring — a day or two of engineering, repeated for every new soft-deletable model. This package collapses that to a composer require. Decision framing: buy if you have 3+ soft-deletable models and no bespoke retention rules; build if you need model-specific restore semantics.
- Roadmap sequencing: data-safety before data-destructive features. Shipping bulk delete, "archive," or importer overwrite flows gets materially safer once a recovery path exists. This lets you green-light destructive admin actions earlier, or widen them to non-technical roles, because the blast radius is reversible.
- Support-cost reduction as a PM-visible metric. "I deleted the wrong record" tickets are a measurable, recurring cost. Track delete/restore-related tickets and restore events per month before and after rollout; a drop in the former with non-zero latter is your value proof.
- Scope setting: this is not compliance. Be explicit that this is an operational undo, not an audit trail, not legal hold, not data-retention policy. If a stakeholder asks for "GDPR/records retention," this package is an ingredient at best — scope a proper audit-log and retention workstream separately.
When to Consider This Package
Adopt when all of these hold:
- You are on Filament v5 and Laravel models already use
SoftDeletes. Filament v5 is new; confirm version compatibility and Filament upgrade cadence in a short spike before committing.
- You have several soft-deletable resources and want one place to look, rather than teaching admins to open each resource and toggle a trashed filter.
- Your team is small and a 1-day build is genuinely scarce, or you want to validate demand for a recycle bin before investing in a bespoke one.
- Your authorization model is simple enough that a page-level gate is acceptable; you can live with policies being enforced per-model inside the page.
Look elsewhere — or build in-house — when:
- Vendor risk is unacceptable. 11 stars, 0 dependents, and a low composite quality score (0.215) mean a single-maintainer, unproven dependency. That's tolerable for an internal admin convenience, not for a customer-facing or regulated surface. Mitigation: pin the version, read the source (it's small enough to audit in an hour), and fork if abandoned.
- You need per-record authorization granularity, audit logging, cascade/relational restore, retention windows, or scheduled purge. None of that is in scope here.
- Your trashed tables are large; a single unified table across models needs to paginate and index well. Load-test with production-like volumes.
- Filament's built-in
TrashedFilter plus restore/force-delete bulk actions already covers ~80% of the per-resource need and costs nothing. Only the centralized view is the differentiator — decide whether that alone justifies a dependency.
How to Consider It (Stakeholders)
For executives: A free, MIT-licensed add-on that gives admins an undo button for deleted records across the whole admin panel. It's small and low-risk, and the payoff is fewer "please recover this" support tickets and a safer path to shipping bulk/batch operations. It is not a compliance or audit feature and not a competitive differentiator — treat it as hygiene, not roadmap.
For engineering: A small, auditable package that replaces a repeated custom build. Ask for: confirmation of Filament v5 compatibility against our pinned version, a source review (size makes this cheap), a check that restore and force-delete respect our model policies, and a fork-and-pin plan in case maintenance lapses. Roll out behind one pilot resource first.
Recommendation: Run a one-sprint spike — install, wire two real resources, verify authorization, and measure restore events plus delete-related tickets for 30 days. Ship if it holds; keep the in-house build as the documented fallback.