Filament Fathom Laravel Package

Product Decisions This Supports

• Panel information architecture (IA) decisions. Plugin::make()->navigationGroup(string|Closure) lets the settings page be filed under an existing navigation group in the host panel instead of a package-supplied translated group. This turns a "where does this live in our admin?" debate into a one-line config choice rather than a fork or a custom page.
• Consolidation vs. per-package menus. Teams that group admin surfaces by domain (e.g. "Insights", "Reporting", "Settings") can now keep analytics settings alongside related configuration. This supports a roadmap decision to standardise on a small number of top-level groups across all admin tooling.
• Multi-panel and multi-tenant rollouts. Because the value accepts a Closure, the group can be resolved at runtime — enabling different groupings per panel, per tenant, or per role without duplicating configuration. Relevant if the roadmap includes separate admin and client-facing panels.
• Localisation and copy decisions. The default behaviour keeps the translated group label. Choosing to override it is an explicit product decision to trade the package's maintained translations for your own naming convention — worth capturing in a design/content guideline rather than leaving to individual developers.
• Dependency and upgrade sequencing. The feature requires filament-analytics-core 3.1. This is a small but real constraint on the upgrade plan: adopting the feature means committing to a minimum core version, which should be sequenced with other panel upgrades rather than decided ad hoc.

When to Consider This Package

Adopt (or adopt this release) when:

• You run a Filament panel and already have established navigation groups that the analytics/settings surface should join; ad hoc placement is currently a visible inconsistency.
• You operate more than one panel or have tenant-specific admin layouts, so a Closure-based group is genuinely useful rather than incidental.
• You are already on, or can move to, filament-analytics-core 3.1 without disruption — the feature is explicitly gated on that version.
• The team values configuration over customisation: solving placement via plugin config avoids maintaining a bespoke settings page.

Look elsewhere or defer when:

• Navigation placement is not a concern — a single-panel app with one settings group gains little from this release.
• You are pinned below core 3.1 and the upgrade cost outweighs the cosmetic benefit; the package's translated default group remains perfectly usable.
• You need deep control over the settings page itself (routing, permissions, layout). A navigation group hook is a placement primitive, not an extensibility story — requirements beyond grouping point to a custom page.
• You require stable, well-established APIs for a long-lived admin surface; verify the Closure signature and evaluation context in the docs before treating it as a runtime tenancy mechanism.

How to Pitch It (Stakeholders)

For executives: A small, low-risk release. It lets our admin panel present the analytics settings page under an existing menu section instead of a standalone one, so the admin area looks and behaves consistently for staff. No breaking changes, no migration work, no new cost — it is configuration, not new surface area. The only dependency note is a minimum version of the underlying analytics core (3.1), which should be folded into the upgrade work already planned rather than treated as a separate project.

For engineering: Adds Plugin::make()->navigationGroup(string|Closure) to control the settings page's navigation group; falls back to the package's translated group when unset. Requires filament-analytics-core 3.1. It is a pure configuration addition — no schema, route, or permission changes — so the practical work is a version bump plus deciding our group naming convention. Recommend we standardise group names in one place and use the Closure form only where panels or tenants genuinely diverge, to avoid config sprawl.