Filament Simple Analytics Laravel Package

Product Decisions This Supports

• Admin information architecture: Plugin::make()->navigationGroup(string|Closure) lets the settings page sit inside one of your panel's existing navigation groups. This is a presentation-layer decision you can now make per panel without forking the package or writing a wrapper page — useful when deciding whether the settings screen belongs under "Settings," "Analytics," or a product-specific group.
• Multi-panel / multi-tenant shaping: the Closure variant means grouping can be resolved at runtime, so different panels or tenants can surface the settings entry in different places from one codebase. This directly supports decisions about whether a single admin panel is enough or whether panel segmentation is warranted.
• Build vs. buy: previously, non-default navigation placement was a plausible reason to hand-roll a small custom Filament page just to control where the entry appears. That justification is now largely gone — one chained builder call replaces bespoke code and its maintenance burden.
• Localization strategy: the default translated group is retained when the option is unused, so adopting this release does not force a copy/i18n review. Teams maintaining translated panels can defer the decision to customize the group label.
• Roadmap signal: 3.1.0 is additive and ergonomic — no data model, storage, consent, or configuration-semantics changes. It does not unlock new user-facing capability, so it should not displace roadmap items; treat it as a quality-of-integration improvement that reduces friction for teams already standardizing their panel navigation.
• Dependency floor as a planning input: the feature requires filament-analytics-core 3.1. If you are pinned below that, this release delivers nothing — capture that as an upgrade dependency in the roadmap rather than a feature commitment.

When to Consider This Package

Consider adopting when:

• You run one or more Filament panels and have an opinion about where package-provided settings pages appear in the sidebar; unmanaged placement is a recurring source of admin UX inconsistency.
• You are consolidating plugin entries into a small, curated set of navigation groups and want that enforced centrally rather than patched per package.
• You support multiple panels or tenants where the same page should appear in different groups — the Closure form is the deciding factor here.
• You are already on, or willing to move to, filament-analytics-core 3.1+ and the rest of the Filament major you are on. The feature is inert otherwise.
• You were previously considering a custom page or a thin in-house wrapper purely to control navigation placement — this removes that build.

Look elsewhere or defer when:

• You are content with the default translated navigation group. This release changes nothing for you; upgrading is optional and carries no functional benefit.
• You are pinned below filament-analytics-core 3.1, or your Filament version constrains you from taking the paired release. Wait for a coordinated bump rather than forcing it.
• You need deeper structural customization — reordering items within a group, badge/count rendering, conditional visibility, or moving the page outside navigation entirely. Navigation group assignment is the whole of this feature; anything beyond it still implies a custom page or an upstream request.
• You are mid-freeze or in a release-candidate window. Additive as it is, there is no product reason to absorb a dependency bump during a lock-down.
• You require a documented support/stability commitment before adding builder-level API surface to your critical path — verify the option's behavior and deprecation posture in the package's docs rather than relying on the release note alone.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk release that improves how one settings screen appears in the admin sidebar. It does not change how the product works, what data is stored, or what customers can do — it removes a reason teams previously had to build and maintain custom admin screens just to control menu placement. There is no cost to staying put; the benefit accrues only to teams actively standardizing their admin navigation.

For engineering: 3.1.0 adds an optional fluent setter, Plugin::make()->navigationGroup(string|Closure), to assign the settings page to one of the panel's own navigation groups. Behavior is opt-in and backwards compatible — omit the call and the existing translated group is preserved, so no locale or menu regressions are expected. Note the hard floor on filament-analytics-core 3.1. The Closure form enables per-panel and per-tenant resolution, which is the variant worth exercising in tests. Suggested verification: register the plugin in at least one panel with a string group and one with a closure, confirm the entry renders in the intended group across locales, and confirm default behavior is unchanged when the call is absent. Treat as a routine minor upgrade; no migration or data backfill is implied by the release note.