Dynamic Action Fields Laravel Package

Product Decisions This Supports

• Backlog triage for internal tooling. This package is a lever on the recurring "ops needs a small admin action" queue. It lets a single Laravel Nova action render different inputs depending on selected resources, acting user, tenant, or record state — so a request that would otherwise become a bespoke admin page can ship as a Nova action instead. That changes the cost estimate on a whole category of tickets, which is a prioritization input, not a one-off feature.
• Build vs. buy for back-office surfaces. For teams already paying for Nova, it's a candidate to replace hand-built admin screens for variable-input workflows: bulk status transitions with reason codes, refunds or credits whose fields differ by type, moderation queues where required fields vary by content type, inventory corrections scoped to selected orders. The decision to evaluate is "extend Nova" versus "build a custom admin surface" — and this package materially widens what the "extend Nova" option covers.
• A bet on operator self-serve over engineering toil. If support and ops currently file engineering tickets for data fixes because the panel can't capture the right inputs, adoption lowers the marginal cost of each new self-serve action. That makes continued internal-tooling investment justifiable as a roadmap line rather than a series of ad hoc favors.
• Roadmap framing for the internal platform. It's evidence that Nova actions can carry enough conditional logic to remain a durable internal-tooling layer — informing the explicit decision of whether to keep investing in Nova or begin migrating to a custom admin surface, rather than drifting into that choice.
• Sequencing and risk appetite. Because it is a low-adoption, effectively single-maintainer dependency, adoption is also a decision about how much operational risk the team is willing to own in-house. That's a PM-visible trade-off and should be recorded as such.
• Explicitly not a customer-facing product decision. It does not change the end-user experience. Frame the business case in internal-tooling ROI, engineering velocity, and reduced ticket volume — not product differentiation.

When to Consider This Package

Consider it when all of the following hold:

• You are already running Laravel Nova in production. This is additive; it is not a reason to adopt Nova and should not factor into a Nova-versus-alternatives evaluation.
• You have repeat action workflows where the right inputs genuinely vary — by selected resource type, prior field value, acting user, tenant, or record state — and a static action form forces either a wall of irrelevant fields or a sprawl of near-duplicate actions.
• You accept the dependency profile: 18 stars, zero dependents, effectively single-maintainer, MIT-licensed. Treat it as source you may vendor or fork, not a vendor you can lean on for SLAs.
• You can read and maintain the PHP yourself, are comfortable pinning a version, and will review diffs on upgrade.
• Your Nova major/minor is explicitly verified against the package. Nova is paid and closed-source, so version drift is the dominant risk; the package's declared constraint is the first thing to check.
• You have — or will build — a smoke test per converted action that opens the modal and asserts the expected field set, so a Nova bump fails loudly in CI rather than silently in front of an operator.

Look elsewhere when:

• You are not on Nova, or are still evaluating Nova itself.
• You need guaranteed maintenance, SLAs, or broad community support on a critical admin path — adoption signals here are thin.
• The variant logic fits native Nova conditional fields, dependsOn, or a handful of separate actions. For a single edge case, the dependency isn't worth it.
• You are planning to migrate off Nova near-term; baking logic into a Nova-specific package compounds that migration cost.
• You need reactive behavior inside the modal (field B updating live as field A changes). Verify actual capability before assuming — one-shot resolution at modal open versus live reactivity are very different risk profiles, and the cascade use case that most justifies the dependency depends entirely on which is true.
• Validation parity is unproven. If validation rules are re-derived separately from the rendered fields, you can get "required but hidden" fields or, worse, values that pass unchecked on data-mutating admin actions. Treat that as a correctness blocker.

How to Pitch It (Stakeholders)

For executives. We already pay for Laravel Nova as our internal admin panel. This small MIT-licensed package lets operations and support run admin actions whose input forms adapt to context — selected records, acting user, data state — instead of every action being one fixed form. The practical effect: we ship more operational self-serve actions without commissioning custom admin screens, which means fewer engineering tickets for routine data fixes and faster turnaround for ops. The risk is vendor-side. It has minimal adoption and is effectively maintained by one person, so we treat it as small code we can fork and own rather than a vendor relationship, and we scope it to internal tooling only — never customer-facing flows. Expected cost is low and bounded: hours per action to integrate, plus a modest re-verification tax on each Nova upgrade.

For engineering. It's a thin Nova extension for dynamic action fields: small surface area, MIT, readable end to end in an afternoon. The mental model is "move fields() into a callback that re-runs against the live request." Adopt it behind a joint version pin on the package and the Nova minor. Convert one low-risk action first, keeping the static fields() implementation behind the trait so rollback is a one-line revert, then observe in production before batching the rest. Add a smoke test per converted action that opens the modal and asserts the expected field set, and wire it into CI — that test is the highest-leverage artifact in the whole integration. Verify three things during the spike, not after: which Nova/PHP versions are actually CI-tested, whether field resolution is one-shot at modal open or reactive to sibling fields, and whether validation runs through the same dynamic resolution path as rendering. Keep the trait behind one base class so a swap is mechanical, inventory every action that depends on it, and budget roughly half a day to vendor-fork or inline the trait if upstream goes quiet. Do not let it become a hidden dependency in customer-facing flows.