Filament Nested Resources Laravel Package

Product Decisions This Supports

• Admin IA: nest vs. flatten. Decide whether hierarchical admin data (project → task, course → lesson, org → team, CMS section → article) deserves true nested routes with parent-scoped tables, forms, and breadcrumbs, or whether flat tables with filters are enough. This package turns "nested" from a custom-engineering project into a cheap-to-evaluate option.
• Build vs. buy vs. use what Filament already ships. It reframes the choice as three-way: Filament's built-in RelationManager for inline child CRUD; custom routing (what this package replaces); or the plugin where children need first-class pages — their own table, filters, widgets, custom pages, and shareable deep links. Applying it to every parent–child pair adds route and breadcrumb surface nobody asked for.
• Roadmap sequencing and admin UX polish. Nested resources are an enabler for parent-aware create/edit flows, deep links to child records, and ancestor breadcrumbs. Release 1.3.0 is a breadcrumb improvement only — a low-risk, schedulable usability item, not a platform change.
• Platform standardization. Establishes one convention for nested resource modeling, URL generation, policy checks, tenant scoping, and breadcrumb behavior, so future admin resources follow a pattern instead of accumulating bespoke route logic.
• Dependency risk-tiering. With effectively no downstream adoption signal (0 dependents) and a community maintainer model, treat this as a tactical admin-layer package, not a core platform bet. Approve for scoped admin use after a pilot; require a fork/vendor contingency if the admin panel becomes business-critical.
• Scope boundary decision. It is explicitly admin-facing. It should not be used to model public-facing nested URLs — that is a separate product and SEO decision.

When to Consider This Package

Consider it when:

• The product runs Laravel + Filament v3, and the admin panel has genuine parent–child workflows that need nested routes, parent-scoped tables/forms, breadcrumbs, and deep links.
• Children need to be first-class resources — their own list/create/edit pages, filters, widgets, or shareable URLs — not just inline rows on the parent screen.
• Engineering wants to eliminate custom nested-routing and breadcrumb plumbing, and can validate one low-risk, admin-only pair first (Project → Task, Course → Lesson).
• The team accepts community-package maintenance, can pin Filament/Laravel constraints, and will name an internal owner plus a thin regression suite for routing, authorization, tenancy, and breadcrumbs.

Look elsewhere or defer when:

• The admin surface isn't Filament-based, most resources are flat, or the nesting requirement is public-facing.
• A RelationManager would do — children only need inline management inside the parent, with no independent pages, filters, or deep links.
• The organization requires a commercial SLA or vendor support contract.
• Multi-tenancy or authorization requirements exceed the package's scope and the team cannot fork/vendor it.
• A Filament major upgrade is imminent without confirmed compatibility. Filament is the primary breaking vector, and with near-zero dependents we will likely discover regressions before the community does.
• Pre-adoption validation: version matrix (Filament/Livewire/Laravel), route model binding, policy enforcement at every nesting level, tenant scoping with two tenants, route-cache behavior, getUrl() parent parameters, global-search URLs, and breadcrumbs across a three-level hierarchy.

How to Pitch It (Stakeholders)

Executives. This package improves admin usability for hierarchical data and removes custom engineering for nested navigation and CRUD — a real but contained efficiency win, not a core platform bet. It is additive and reversible: adoption happens one resource pair at a time, so cost is priced per pair rather than as a big-bang admin rewrite. Release 1.3.0 is a minor breadcrumb/UX improvement with low upgrade risk. The material caveat is that the package has essentially no downstream adoption signal and a small maintainer pool, so we should adopt through a scoped pilot and hold a fork/vendor contingency if the admin panel becomes business-critical.

Engineering. Use this to standardize nested Filament resources instead of maintaining custom routing and breadcrumb code. Install is quick — Composer, publish config, add the NestedResource trait, declare parent resource and relationship, hide the child from navigation — but the real cost is information architecture and authorization modeling. Every parent–child pair needs a matching Eloquent relationship, and every deep link into a child now carries the parent record, so getUrl() call sites in widgets, notifications, custom actions, and global-search results all need auditing. Plan one to two engineer-days for a first production pair, not one hour. Start with one two-level pair on a staging branch, keep flat child routes live during transition, then expand pair by pair. Note the trap: relationship scoping prevents cross-parent access but is not a policy check — enforce both.

Pilot exit criteria to agree up front: zero 404s across the nested route set after route:clear and re-cache; policy checks verified for all four verbs plus a second-tenant negative test; breadcrumbs render every ancestor as a link and the current record as plain text at three levels; and no N+1 introduced on the nested index (asserted by query count). Document the "when to nest vs. when to use a RelationManager" guideline before rolling out further, and name one engineer accountable for the version pin, the convention doc, and the regression suite.