Nova Global Filter Laravel Package

Product Decisions This Supports

• Dashboard feature scoping: Decide whether Nova metrics and custom cards should inherit the same filters users already apply on resource indexes, instead of building separate card-level filter controls.
• Build vs. buy: Use this package to avoid custom plumbing that broadcasts Nova filter state into metrics/cards. It is a narrow, MIT-licensed accelerator rather than a platform commitment.
• Roadmap sequencing: Prioritize “consistent analytics filtering” as a small, high-leverage admin experience improvement if your team already relies on Nova filters.
• Use-case validation: Test demand for segmented KPI dashboards, support/ops metrics, revenue or usage cards, and other Nova cards that need to follow a global filter.
• Adoption risk decision: Treat the package as a pilot candidate, not a strategic dependency, given zero stars/dependents and limited ecosystem validation.

When to Consider This Package

• Your admin/back-office is built on Laravel Nova, and users already depend on existing Nova filters.
• You need metrics or custom cards to respect a global filter without rebuilding filter logic per card.
• The scope is an internal dashboard or operational reporting surface where a lightweight package is acceptable.
• You can review, test, and possibly fork the package; you have engineering capacity to own the integration.
• You want a fast proof of concept before investing in a broader internal analytics or filtering layer.

Look elsewhere when you are not on Nova, need filtering across non-Nova surfaces, require vendor-backed support/SLA, need advanced filter composition beyond Nova’s model, or cannot tolerate low-adoption dependency risk. If dashboards are customer-facing or business-critical, prefer a more proven or internally owned solution.

How to Pitch It (Stakeholders)

Executive summary: This is a low-cost, MIT-licensed Nova add-on that lets existing admin filters flow into metrics and custom cards. It can improve dashboard consistency and reduce custom engineering for internal reporting, but it is early-stage with little adoption. Recommend a limited pilot on a non-critical Nova dashboard, with engineering review and a fallback plan to fork or replace if maintenance or compatibility issues appear.

Engineering framing: Reuse existing Nova filter definitions instead of building a bespoke broadcast layer. Validate compatibility with your Nova version, test filter state behavior across cards, and confirm the package is maintainable enough to own. Do not make it a hard dependency until the pilot proves value and stability.