Product Decisions This Supports
- Admin panel UX scope decisions: This package adds a single-purpose Filament table column that renders an interactive toggle icon (e.g., on/off, active/inactive) directly in a Filament resource list. It informs decisions about how much interaction to embed in admin list views versus routing users to edit forms.
- Build vs. buy for internal tooling: For teams building Filament-based admin panels, this is a clear "buy" (adopt) candidate — it replaces a small but recurring custom column implementation with a maintained, MIT-licensed package.
- Roadmap sequencing for admin/back-office features: Because v3.2.0 adds Laravel 12 support, teams planning a Laravel 12 upgrade can keep inline-toggle workflows on the roadmap instead of deferring them or hand-rolling a workaround.
- Platform standardization: Signals that the Filament v3 + Laravel 12 stack remains viable for back-office products, supporting decisions to standardize internal admin tooling on Filament plugins rather than bespoke Blade/Livewire components.
- Use cases: user activation toggles, feature-flag switches per record, published/draft visibility, "featured" markers — any boolean state a support or ops team needs to flip without opening an edit page.
When to Consider This Package
Adopt when:
- You are on Filament v3 and need a compact, clickable boolean-state column in table listings.
- Your team already uses Filament and wants to avoid maintaining a custom column class for a common pattern.
- You are planning or executing a Laravel 12 upgrade — v3.2.0 explicitly adds Laravel 12 compatibility, so this release removes a blocker.
- The interaction is genuinely a quick toggle: the workflow benefits from avoiding a full edit-page round trip (support triage, ops dashboards, moderation queues).
- You want a small, single-responsibility dependency rather than a broad admin suite.
Look elsewhere or build in-house when:
- You are not on Filament — this package has no value outside that ecosystem.
- You need auditability, authorization granularity, or confirmation flows on state changes. A one-click toggle in a table row can bypass the policies and audit trails you'd get through a form action; verify your authorization and activity-logging story before adopting.
- You need bulk toggling, optimistic UI at scale, or complex state machines — a dedicated action/column implementation or a richer package is a better fit.
- You require a vendor with a support contract or SLA. This is a single-maintainer, community package; the v3.2.0 changelog is dominated by dependency bumps and a framework-compatibility PR, which is a reasonable signal of maintenance but not of commercial support depth.
- Your Filament major version is outside what the release supports — confirm Filament version constraints in
composer.json before committing, since the notes only call out Laravel 12.
How to Pitch It (Stakeholders)
For executives (one paragraph): We're evaluating a small, free, open-source add-on for our admin panel framework (Filament) that lets staff flip on/off states — active users, published items, featured flags — directly from a list view instead of opening each record. The newest release (v3.2.0) adds support for Laravel 12, the framework version on our upgrade path, which means adopting it doesn't create a future migration blocker. Cost is zero, license is permissive, and the scope is deliberately narrow, so downside risk is low. The main caveat is governance: because toggles happen inline, we need to confirm that permission checks and audit logging still apply before we roll it out to sensitive data.
For engineering leads: v3.2.0 is a compatibility and maintenance release — Laravel 12 support plus routine Dependabot bumps to CI tooling (laravel-pint-action, fetch-metadata). No breaking changes, no deprecations, no new public API surface. That makes it a low-risk minor upgrade from v3.1.1. Two things to validate before we standardize: (1) the package's Filament version constraint still matches our pinned Filament major, and (2) inline toggle actions respect our policy/authorization layer and emit audit events — if they don't, we wrap the column with a custom action that does, or restrict it to non-sensitive resources. Recommend a spike on one low-risk resource, then a decision on broader adoption. Note the package is single-maintainer; pin the version in composer.json and track upstream releases rather than floating.