Filament Crisp Laravel Package

Product Decisions This Supports

• Admin information architecture / navigation design. Plugin::make()->navigationGroup(...) lets you file the analytics settings page into an existing panel navigation group instead of living in its own translated "Analytics" group. This is a UX-consistency decision: does analytics configuration sit alongside other settings, or stand alone as a first-class section? The answer is now configurable per panel rather than dictated by the package.
• Multi-panel and multi-tenant product shapes. Because the group is set per-plugin-instance and accepts a Closure, you can vary placement per panel (admin vs. tenant vs. white-label) — useful if different audiences should see analytics configuration in different contexts.
• White-labeling and localization decisions. The default remains the translated group, so non-English panels keep sensible out-of-the-box behavior; the override is opt-in. This lowers the friction of shipping a localized admin without patching views or navigation.
• Build vs. buy for admin surfaces. The plugin continues to absorb small, high-friction customization asks (navigation placement) that would otherwise become in-house view overrides — a modest but real maintenance-cost argument in favor of keeping it.
• Upgrade/roadmap sequencing. The feature is gated on filament-analytics-core 3.1. That's a dependency-version decision, not just a feature toggle: your roadmap item is "upgrade core to 3.1" before "reorganize admin navigation."

When to Consider This Package

Adopt (or continue with) this plugin when:

• You are already on (or willing to move to) filament-analytics-core 3.1+; the new navigation feature is unavailable on earlier cores.
• You run a Filament panel where admin navigation grouping matters to users — typically multiple settings modules, a documented IA, or a localized admin that must read consistently.
• You need per-panel or conditional placement; a string is enough for most teams, a Closure covers panels that branch on tenant, role, or feature flag.
• You want navigation behavior configurable at the plugin registration level rather than through view overrides or custom pages.

Look elsewhere or defer when:

• You are pinned below core 3.1 — treat this release as a no-op and do not let it drive an upgrade on its own.
• Navigation placement is irrelevant (single settings page, no user-facing admin, or you already override navigation wholesale).
• You need deeper layout control than group placement (ordering, icons, nested items, badges). This release covers grouping only; other navigation attributes remain out of scope and may require custom work.
• Your environment has strict dependency-pinning rules that make coordinated minor-version bumps expensive relative to the benefit.

How to Pitch It (Stakeholders)

For executives: The analytics admin plugin shipped a small configurability release (3.1.0) that lets us choose where the analytics settings page appears in our admin navigation, instead of accepting the package's default placement. It's a low-risk, opt-in change — default behavior is unchanged — and it removes a recurring reason teams patch or fork the package for cosmetic reasons. It requires the companion core library at 3.1, so the practical ask is "bundle this with our next routine core upgrade," not a standalone initiative.

For engineering: Plugin::make()->navigationGroup(string|Closure) binds the settings page to an existing panel navigation group; omitting it preserves the translated default group. Requires filament-analytics-core 3.1. Non-breaking, config-only, no migration. Recommend bumping core and the plugin together, then setting the group explicitly in each panel provider so navigation intent is declared in code rather than inherited from package defaults — and add a test asserting the registered group per panel if panels diverge.