Nova Boolean Group Field Laravel Package

Product Decisions This Supports

• Admin workflow ROI vs. custom build: When the roadmap already includes Laravel Nova for back-office operations, this package is a cheap way to collapse a scattered set of toggles into one grouped control. The decision it supports is build-vs-buy for low-differentiation admin UI — the kind of work that never shows up on a roadmap but consumes design and engineering cycles anyway. Adopt where the alternative is an in-house Nova field, not where the alternative is a real product feature.
• Scoping the data model between "admin setting" and "domain concept": The package stores selections as a single JSON attribute, which is a signal as much as a mechanism. It supports the call that notification preferences, module access, or beta-invite flags are configuration, not first-class entities. The moment the product needs per-flag history, reporting, per-tenant isolation, or an external API contract over those flags, that decision has flipped and the JSON column becomes technical debt rather than a shortcut.
• Prioritization and sequencing: This is an internal-efficiency lever, not a revenue driver. Frame it as a way to shave effort off configuration-heavy admin screens so the team can spend roadmap capacity on customer-facing work. It should never displace a higher-impact initiative, and it should be scheduled as opportunistic cleanup rather than a planned epic.
• Risk posture for tactical dependencies: With 7 stars, zero dependents, and a last release in March 2024, the supported decision is pilot, not platform standard. Approve adoption only where blast radius is low (admin-only, reversible, a handful of users) and where the exit ramp is documented — reverting to Nova's native BooleanGroup or an in-house fork should be a one-file change, not a migration project.
• Feature-flag and permission-bundle experiments: For small, closed option sets (four to eight flags), the grouped control makes admin intent readable at a glance and reduces misconfiguration. It supports fast iteration on internal tooling — but it is explicitly not the substrate for compliance-grade permissions or customer-facing feature-flag infrastructure.

When to Consider This Package

• Consider it when the product is already running Laravel Nova, the need is confined to internal admin screens, and grouping multiple booleans into one control measurably improves admin speed or reduces errors (for example: notification channels, module entitlements, onboarding steps, beta access).
• Consider it when the option set is small, fixed, and non-critical, occasional UI regressions are tolerable, and admins have a workaround or a support path if something breaks.
• Consider it when the fallback is genuinely cheap: Nova's built-in BooleanGroup covers most of the same ground, so adoption should hinge on a specific, nameable gap (option labels and defaults, layout, display rendering) that justifies the extra dependency.
• Consider it only after verifying Nova/Laravel/PHP version constraints, storage-format parity with native BooleanGroup, whether frontend assets ship prebuilt, and field-level authorization behavior. The README is thin — the source in vendor/ is the real documentation, and that review is a prerequisite, not a nice-to-have.
• Look elsewhere or build in-house when the flags are customer-facing, compliance-sensitive, or need audit history, conditional logic, multi-tenant isolation, or per-flag metadata such as descriptions and timestamps. Those are the triggers to promote the flags into a proper table or model.
• Look elsewhere when the team is not on Nova (adding Nova to use one field is a non-starter), when the organization requires vendor support or SLAs, or when the team cannot absorb the maintenance risk — no dependents, no visible test suite, and Nova 5 compatibility unverified means you own the regression surface.
• Watch for an option-set growth signal: four to eight flags read well in a grouped control; twenty do not. If the list keeps growing, that is a design signal to migrate the data model, not a reason to add another ->options() entry.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost, reversible improvement for internal admin users already on Laravel Nova. It reduces custom UI build effort and speeds up configuration-heavy back-office screens, but it is not a customer-facing differentiator or a strategic platform bet. Approve it as a tactical dependency with a named owner, a pinned version, a defined pilot scope (one admin screen, low-risk settings), and a documented fallback to Nova's native field. The decision is not "should we standardize on this" — it is "should we spend a small amount of effort here instead of building it ourselves."

For engineering: This is an MIT-licensed Nova custom field that groups boolean options into one form control and persists the selections as a JSON/array attribute on an Eloquent model. Adopt it behind a thin internal wrapper (a single field factory) so a fork or a revert to native BooleanGroup stays a one-file change; keep the option keys in config or an enum so the form, the validation rules, and the read-side helpers can't drift. Normalize on read by merging stored values over a defaults array, validate keys explicitly, add the array cast in the same commit as the migration, and confirm mass assignment, asset build, and field-level authorization before rollout. Because there are zero dependents and no visible test suite, the team owns the regression surface — a feature test that posts a preference payload through the Nova endpoint and asserts the stored JSON is the minimum insurance. Pin Nova and this package together, and re-run the CRUD/validation/permission pass on every Nova upgrade; Nova 5 compatibility is unverified.