Product Decisions This Supports
- Form UX for related-record selection. Anywhere an admin picks a child record (City, Account, SKU, Ticket, Project Task) whose valid set depends on another field already chosen (Country, Region, Client, Warehouse, Project), this package turns a flat, error-prone dropdown into a contextual one. That is a discrete, demoable UX improvement — good for a roadmap line item that ships in days, not quarters.
- Data-quality / invalid-combination reduction. Dependent filtering is a prevention control: it stops operators from pairing a task with a project it doesn't belong to, or a contact with the wrong account. Frame the business case as fewer correction tickets and cleaner downstream reporting, not as a feature.
- Build vs. buy for admin-panel polish. The alternative is a custom Nova field or a
BelongsTo subclass maintained in-house. This package is a thin extension of an existing Nova field, so the real decision is "vendor a ~100-line package" vs. "write ~100 lines ourselves." Either is cheap; the decision should be made on maintenance ownership, not capability.
- Scoping internal-tool roadmaps. Useful as a reference for how far you can push Nova before needing a custom front end. If requirements stay at "filter dropdown by sibling field," stay in Nova; if they escalate to multi-level cascades, cross-resource search, or permission-scoped options, that's the signal to budget a custom admin surface.
- Backlog triage. Lets you defer "better admin UX" requests cheaply instead of letting them accumulate into an argument for replacing Nova.
When to Consider This Package
Adopt when all of these hold:
- You are on Laravel Nova (this is Nova-only — it delivers zero value outside a Nova admin panel, so confirm Nova is a committed part of your stack).
- The need is genuinely one-hop dependency: one controlling field constraining one searchable
BelongsTo. Not two-hop cascades, not multi-field composite filtering.
- The admin panel is internal and low-blast-radius — an ops or back-office tool, not a customer-facing surface where a broken field is a revenue event.
- You are willing to fork it on day one. With zero stars, zero dependents, and a single maintainer, treat the repo as a reference implementation you own, not a dependency you consume. Pin it, vendor it, read the source (it's small), and be prepared to maintain it yourself.
- You can verify Nova version compatibility against your installed version before committing — Nova's field internals have shifted across majors, and an unproven package is exactly where that breaks silently.
Look elsewhere (or build in-house) when:
- You need this on Nova 5+ / current Nova. No evidence of active maintenance; assume incompatibility until proven.
- Dependency rules must be enforced server-side. Client-side dropdown filtering is UX, not validation. You still need a
Rule/FormRequest guard on write — don't let a filtered dropdown be mistaken for a data-integrity control.
- Option sets are large. Filtering a searchable field that itself pages through thousands of records compounds latency; you'll want index-backed search columns or an async/remote search strategy.
- You need multi-level or conditional-on-conditional behavior. Scope creep here is a custom field, not a config tweak.
- Your team has a policy against single-maintainer, zero-adoption dependencies. Reasonable policy; then copy the approach instead of the package.
How to Pitch It (Stakeholders)
To executives: A small, low-cost enhancement to our internal admin tooling that prevents operators from selecting invalid record combinations — fewer correction requests, cleaner data entering our reports. Estimated effort is measured in days. Risk is contained because the admin panel is internal and the change is a dropdown behavior, not a data model change.
To engineering: A thin Nova extension that constrains a searchable BelongsTo field's options by the value of another field — cascading-select behavior inside Nova's existing field API. The upside is that it's small enough to read in one sitting and cheap to fork. The caveats are real and should be stated plainly: no stars, no dependents, one maintainer, unverified Nova version support. Recommend we vendor/fork it, pin it, add a server-side validation rule alongside it (the filter is UX, not enforcement), and verify against our Nova version before we put it on the roadmap as committed work.
Honest framing for the decision meeting: this is not a strategic bet. It's a tactical convenience with a maintenance tail we should accept deliberately, or skip by writing the equivalent field ourselves in roughly the same time it takes to evaluate it.