Nova Detached Actions Laravel Package

Product Decisions This Supports

• Deciding whether "global admin operations" deserve a first-class home. Nova's action model assumes row selection, which pushes whole-dataset operations (import, full export, sync trigger, cache rebuild, recalculate-all) into bespoke screens or "select all, then act" workarounds. This package lets the roadmap treat those as a named, discoverable surface — the admin toolbar — instead of scattered one-offs. If at least two such operations are on the backlog, that is a product-surface decision worth making deliberately.
• Standardizing internal admin UX versus accumulating snowflakes. Teams solve this today with toolbar overrides, custom Vue cards, or standalone pages — each a snowflake. Agreeing on one convention pays off the moment multiple internal teams share a Nova install. This package is the cheapest way to buy that convention, and framing it as a pattern decision rather than a code-volume decision is the right altitude for a PM.
• Clarifying a build-vs-buy call where "build" is genuinely cheap. The capability is roughly 50 lines of registration glue. Adopting buys speed and a house pattern; forking buys control. Either way, the PM's job is to pick the pattern and name an owner, not to litigate line counts.
• Forcing guardrail answers for dangerous global actions. Detached actions run with no selection context, so confirmation dialogs, authorization policies, and audit visibility become explicit product decisions. Adoption forces the team to answer "who can clear the cache from a toolbar button?" — a question worth answering regardless of tooling.
• Ops and support throughput. For staff doing repetitive whole-dataset tasks, eliminating the select-all-then-act dance is a measurable click reduction on high-frequency workflows. Quantify it against actual admin session data before committing.
• Roadmap sequencing. Because the value sits entirely in the toolbar placement layer, defer this until at least two qualifying actions exist. It is a consolidation move, not a discovery move.

When to Consider This Package

Adopt when all of the following hold:

• Laravel Nova is already the committed admin layer. The package has zero value outside Nova, and Nova is a paid product — treat this as additive cost only for teams already paying.
• Two or more genuinely resource-independent actions are on the roadmap or in the backlog, so the abstraction amortizes rather than being a one-off override.
• The dependency can be treated as vendored or forked source rather than a trusted upstream package. With 11 stars, 0 dependents, and a single maintainer, budget for owning the code.
• Confirmation dialogs and Nova authorization policies can be enforced around every detached action, with a review checklist in place.
• Someone is named as owner, and the dependency register records the fork intent and exit plan.

Look elsewhere — or write it yourself in roughly 50 lines — when:

• You are not on Nova, or are still evaluating Nova alternatives.
• Only one action is needed; a one-off toolbar override is cheaper than a dependency review.
• Nova's native standalone actions or a custom tool page already cover the surface on your pinned version, leaving only the index toolbar uncovered.
• The organization requires vendor SLAs, security review of maintained dependencies, or a documented bus factor above one. Low stars and zero dependents mean no ecosystem validation: no downstream projects to surface breakage before you do, no community patches.
• You are on an unpinned or newly upgraded Nova major. Small Nova tools are the first to break on Nova upgrades, and the failure mode is silent non-rendering.
• Actions semantically depend on a selection. Anything that expects $models should remain a standard Nova action.

Practical gate before approval: confirm the package's laravel/nova constraint covers your pinned Nova version, and confirm native standalone actions do not already solve it. Nova is closed-source and version-locked, so this is the real feasibility check, not code complexity.

How to Pitch It (Stakeholders)

To executives. This is a free, MIT-licensed convenience layer for the admin panel we already pay for. It lets staff run whole-dataset operations — imports, exports, syncs, cache rebuilds — from a single toolbar button instead of a multi-step "select everything, then act" flow. Direct cost is effectively zero. The real cost is ownership: the project is small, has one maintainer and essentially no community validation, so we would own the code in practice. Recommendation: adopt only if we have at least two such operations and a named owner, and vendor or fork it behind our own namespace rather than treating it as a trusted upstream dependency. Classify it as tactical internal tooling in the dependency register, not strategic infrastructure.

To engineering. It closes a real, narrow gap in Nova's action model with a thin and readable layer that reuses Nova's existing action pipeline — fields, confirmation modals, authorizedToRun(), response handling, and queued execution. Treat it as source, not as a product: fork it, pin the Nova version explicitly, and add a smoke test around toolbar rendering so a silent post-upgrade disappearance is caught. Verify four things before broad rollout — Nova version-constraint compatibility, authorization still gating detached actions, shouldQueue and chunking behavior on long-running operations, and whether detached runs land in ActionEvent for audit history. Audit every ported action for $models assumptions, since there is no selection to imply scope. Enforce idempotency keys on anything mutating, because a toolbar button invites double-clicks. If the fork drifts more than a few Nova releases behind, reimplement — the surface area is small enough that reimplementation is a legitimate escape hatch.

Decision framing. Low cost, low risk, low support burden, with a high-severity tail risk if authorization is bypassed. Approve as tactical internal tooling with a named owner, a documented fork procedure, and a pilot action that proves authorization, queueing, and audit behaviour before the pattern is rolled out more widely.