Filament Simple Permissions Laravel Package

Product Decisions This Supports

• Build vs. buy on admin access control. Rather than speccing a roles-and-permissions screen, a team can stand up a Filament resource for roles/permissions and spend that sprint on the actual product. The honest comparison is not "buy vs. build" but "adopt this abandoned package vs. adopt a maintained one vs. build" — see the next section.
• Persona segmentation inside internal tooling. The package's real product value is enabling support, finance, content, and ops teams to share one admin panel with scoped access, without engineering hand-holding per request.
• Deflecting a recurring ticket class. Self-serve role assignment by an ops lead ("give Y access to X") converts an engineering interrupt into a UI action. This is the strongest ROI argument and the easiest to measure post-launch.
• Roadmap scoping: RBAC as a phase, not a pillar. Adopting it supports a "basic internal RBAC now" milestone; it explicitly does not support an "enterprise RBAC" milestone. That boundary should be written into the roadmap so nobody later assumes role management exists in the sense the security team means it.
• Use cases that fit: internal back-office panels, small role sets (<~10), single guard, MVP/prototype timelines, teams already standardized on spatie/laravel-permission.
• Decisions this does not support, and should be recorded as deferred: SSO/IdP group sync, per-record or per-tenant scoping, audit trails, approval workflows, time-bound access, and access reviews for SOC 2 / HIPAA / GDPR. These are re-implementations, not configuration.
• Meta-decision. Because the repo is archived (last release mid-2023, 11 stars, one maintainer), adoption is a decision to own a small codebase, not to consume a supported product. That should be an explicit, signed-off trade-off rather than an implicit one.

When to Consider This Package

Consider it when:

• The panel is internal-only, low-traffic, and single-guard, and the role model is flat (role → permissions, no inheritance).
• You're already on spatie/laravel-permission; this package is a thin UI layer over it, so the storage model is a known quantity rather than a bespoke schema.
• You have a named owner who will track Filament compatibility themselves and can fork the package if upstream goes quiet — which it already has.
• The horizon is short: an MVP, a demo, or a panel you expect to replace or migrate within a year.
• You've verified Filament compatibility by spike. Given the archive date, assume Filament 3/4 support is not there until proven otherwise; this is the gating question, not a footnote.

Look elsewhere when:

• Default recommendation: an actively maintained alternative (e.g. filament-shield). At 11 stars and archived, this package needs a specific reason to be chosen over the obvious incumbent — "it's simpler" is not sufficient justification on its own.
• Access control is compliance-scoped, customer-facing, or subject to external audit — no security policy, no disclosure path, no patches.
• You need multi-tenancy, record-level scoping, multi-guard setups, or permissions that vary per panel.
• The role editor must not be visible on every panel; the plugin registers per-panel, and a customer-facing panel gaining a role editor is a serious misconfiguration risk.
• Someone will ask "who supports this?" and the answer "we do, eventually" isn't acceptable to the stakeholders in the room.
• Permission-check volume is high or the role graph is large — lookup performance hasn't been benchmarked, so treat that as unvalidated rather than fine.

How to Pitch It (Stakeholders)

To executives: "It's a small open-source add-on that gives our internal admin panel a working role-management screen in roughly a day rather than a sprint or two. Two caveats up front: it's been unmaintained since 2023, and it's only appropriate for internal tooling — not customer-facing or compliance-scoped access control. We'd be adopting a small piece of code we're prepared to maintain ourselves, not buying a supported product. Best framed as a scheduling accelerator with a known ownership cost, not a strategic dependency."

To engineering: "Thin Filament plugin over spatie/laravel-permission — a RoleResource plus config wiring for label, navigation group, and guard. Enforcement stays in our policies and Gate; the package manages data, not authorization decisions. Risks are concrete: guard misalignment between the panel and permission.php, permission-cache staleness after seeding, and Gate::before super-admin bypasses that silently over-grant. Upstream is archived, so budget for a named owner on Filament compatibility and keep a fork escape hatch. Sequence it: pin the version, spike in a non-production panel, prove deny-by-default with a test, then decide the storage and guard model before anyone touches the data model."

To product/ops: "This unblocks self-serve access management for the ops team and should cut the 'please give X access to Y' tickets. It does not get us SSO-driven roles, audit trails, or access reviews — so please don't commit those in customer or auditor conversations on the strength of this. Treat it as an internal convenience that we own, and expect a migration cost if we ever need real enterprise RBAC."