Filament Multi Guard Laravel Package

Product Decisions This Supports

• Legacy System Modernization: Justifies continued investment in Filament v2 (if migration to v3 is delayed) by enabling granular, context-aware role-based access control (RBAC) without a full rewrite.
• Multi-Tenant or Role-Specific Admin Panels: Enables build vs. buy decision for projects requiring isolated admin dashboards (e.g., SaaS platforms, franchises, or departmental tools) where Filament’s native guards are insufficient.
• Phased Feature Rollout: Supports roadmap prioritization for RBAC by allowing teams to implement context-specific permissions incrementally (e.g., "Admin Panel A" for support vs. "Admin Panel B" for marketing).
• Compliance/Regulatory Use Cases: Facilitates audit trails or data segregation (e.g., HIPAA/GDPR) by restricting access to resources/pages/widgets based on dynamic contexts (e.g., tenant_id, user_role).
• Cost Optimization: Avoids custom development of guard systems for Filament v2, reducing dev time and technical debt.

When to Consider This Package

• Use this package if:

  • You’re locked into Filament v2 (v3 has native multi-guard support).
  • Your app requires dynamic, context-aware permissions (e.g., tenant isolation, role-specific dashboards).
  • You need fine-grained control over resource/page/widget visibility without rewriting Filament’s core.
  • Your team lacks bandwidth to build a custom guard system from scratch.

• Look elsewhere if:

  • You’re migrating to Filament v3 (native support exists; avoid dependency bloat).
  • Your use case is simple (e.g., single guard for all users; Filament’s built-in guards suffice).
  • You need active maintenance (last release in 2023; evaluate risk of stale dependencies).
  • Your project requires enterprise-grade RBAC (consider dedicated packages like Spatie’s or custom solutions).

How to Pitch It (Stakeholders)

For Executives:

"This package lets us segment admin access in Filament v2 without a costly rewrite*, enabling us to serve multiple teams/departments with isolated dashboards (e.g., support vs. sales). For example, a SaaS client could restrict tenant A’s admins from seeing tenant B’s data—reducing compliance risk and improving UX. It’s a low-risk, high-reward way to add granular permissions while we plan our Filament v3 migration."*

For Engineering:

*"filament-multi-guard solves the v2 limitation of single-guard contexts by letting us register multiple guard providers (e.g., tenant_guard, role_guard) per route/path. Key benefits:

• No core Filament changes: Plugs into existing v2 setup.
• Dynamic contexts: Supports canAccess() checks with custom logic (e.g., guard('tenant')->check()).
• Future-proof: If we migrate to v3, we can phase this out (native support exists). Tradeoff: Last updated in 2023, but the MIT license and minimal dependencies make it easy to fork if needed. Recommend a POC with 1–2 high-priority contexts (e.g., tenant isolation) before full adoption."*