Filament User Laravel Package

Product Decisions This Supports

• Build vs. buy for the admin/back office. The 2.0.0 dependency set — filament-export, filament-impersonate, spatie/laravel-permission, bezhansalleh/filament-shield — describes an opinionated Filament admin starter: RBAC, support impersonation, and data export pre-wired. That is typically 2–4 engineer-weeks of scaffolding you would otherwise fund.
• Roadmap sequencing. If the next milestone involves any internal tool, ops console, or customer-support surface, this lets you ship the shell and spend the roadmap on domain features instead of auth and roles plumbing.
• Feature scoping, not just tech selection. Impersonation being a first-class dependency is a product decision: it legitimizes "log in as customer" support workflows. It warrants a policy sign-off (consent, audit trail, who may impersonate whom) before it ships.
• Committing to export in the roadmap. Export is table stakes for B2B admin users and a recurring sales/CS ask. Bundled here means you can promise it without a discovery spike.
• RBAC strategy. Depending on spatie/laravel-permission rather than rolling your own is the right default, and filament-shield puts an admin UI on top so permission management stops being a recurring engineering ticket.

When to Consider This Package

Consider adoption when:

• You are on Laravel + Filament already, or are choosing an admin stack with no strong reason to go elsewhere.
• You need standard admin primitives (roles/permissions, impersonation, exports) and have no unusual compliance constraints.
• Your team is small and would rather inherit an opinionated baseline than assemble four plugins yourselves.
• You can absorb the Filament major-version cadence as a roadmap dependency.

Look elsewhere, or proceed with caution, when:

• You are not committed to Filament. The entire value proposition is Filament-shaped.
• You have dependency governance (SCA, pinned versions, SBOM). The * constraints on filament-export and filament-shield are a genuine supply-chain and reproducibility risk — an upstream break can land in your build with no change on your side. This is the single biggest item to resolve before adoption.
• spatie/laravel-permission ^5.8 is behind the current major. It is the load-bearing piece for authorization; confirm the intended upgrade path.
• Your permission model is non-trivial (row-level, multi-tenant scoping, attribute-based). Shield is UI over a role/permission table; it will not cover that without custom work.
• You need audited, hardened impersonation (session isolation, approval workflow, immutable logs). A convenience plugin gives you the verb, not the governance.
• The value is mostly glue. A 2.0.0 whose only apparent change is a dependency set suggests thin in-house code — so weigh "copy these composer lines into our own starter kit" against taking on the dependency.

How to Pitch It (Stakeholders)

Executives: "Adopt this to buy back several weeks of admin-panel plumbing — roles, permissions, support impersonation, and exports come pre-built instead of us writing them. The cost is a dependency on Filament and four of its plugins, which we should pin before committing. Two items need a decision from us: an impersonation policy, and dependency pinning as an adoption gate."

Engineering: "It is a thin, opinionated composition layer over four well-known Filament/Spatie packages. Low code volume means low lock-in — but it also means it is mostly orchestration, and we should be comfortable owning the upgrade path if the package stalls. Before merging: replace the * constraints with pins, confirm Filament major-version alignment across all four dependencies, and verify the laravel-permission 5.x upgrade path. Treat impersonation as a security surface, not a convenience toggle."