Nova Workflow Laravel Package

Product Decisions This Supports

• Build vs. buy for approval/state-machine UI. Backs a decision to ship an internal approval flow (e.g., draft → review → approved → published) in days by layering states and transitions onto an existing Nova resource, instead of commissioning a bespoke workflow engine or a BPMN platform.
• Roadmap sequencing for internal tooling. Lets you treat "ops can move records through states without a developer" as a small, low-cost increment on an existing admin panel rather than a standalone initiative — useful when prioritizing back-office enablement against customer-facing work.
• Scope of the MVP. The package constrains you to a simple, admin-driven state machine. That is a feature for scoping: it forces the team to define states, transitions, and who may perform them explicitly, which becomes the spec regardless of whether you later replace the implementation.
• Concrete use cases to evaluate against: content/publishing review queues, order or refund status handling, leave and expense approvals, ticket escalation and assignment, KYC/onboarding checklists, vendor or contract lifecycle tracking. Common thread: low-to-moderate volume, internal operators, a handful of states, human-in-the-loop decisions.
• Admin-layer strategy. Informs whether Nova remains your internal console of choice. Adopting this package is a soft commitment to Nova; if Nova is not already paid for and deployed, the true cost of this decision is a Nova license plus team familiarity, not just the package.
• Operational metrics. If transition history is captured, it unlocks cycle-time and bottleneck reporting (time-in-state, approval latency) that is otherwise invisible — worth confirming in a spike before you promise it to stakeholders.
• Vendor-risk posture. With 22 stars and no release since April 2022, the decision this supports is not "adopt a dependency" but "adopt a small piece of code we are prepared to own." That reframing changes who signs off.

When to Consider This Package

Consider it when:

• Laravel Nova is already installed, licensed, and the team is comfortable with it; the version in use is compatible with the package (verify against your Nova major version during a timeboxed spike — the 2022 release predates recent Nova majors).
• The workflow is genuinely modest: a linear or lightly branching set of states, human-triggered transitions, one record type at a time.
• The audience is internal operators or support staff, not end customers, and volumes are low enough that you do not need queued, atomic, or idempotent transitions under contention.
• You need it this sprint. A two-to-three day spike to prove the flow, with a fork vendored into the repo, is a reasonable trade against a multi-week build.
• You accept ownership: budget for pinning the dependency, forking it, and assigning a named maintainer.

Look elsewhere when:

• Nova is not in place, is being phased out, or the team has no appetite for a commercial admin dependency. A plain state-machine library (e.g., Symfony Workflow) plus your own UI is a cleaner long-term bet.
• You need real orchestration: parallel branches, timers and SLA escalations, compensation/rollback, cross-service sagas, event-driven transitions, or high concurrency where two operators may act at once.
• Customer-facing or regulated flows demand audited, tamper-evident history, segregation of duties, or vendor SLAs and security review. A near-dormant single-maintainer package will not clear procurement.
• You require active maintenance, prompt security patching, or support for the current Nova release.
• Volume or latency requirements mean transitions must be queued, retried, and observable — this is an admin convenience layer, not a workflow runtime.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost accelerant for internal operations, not a platform commitment. It lets non-technical staff move records — approvals, publishing, order status — through defined steps from the admin panel we already run, which we can prove out in under a week instead of a multi-week build. The trade-off is maturity: the project is a single-maintainer package with a 2022 release, so we should treat any code we take as ours to maintain, cap the exposure, and keep the state definitions portable. Recommended ask: a timeboxed spike, not a roadmap line item.

To engineering: It is a thin Nova layer over model states and transitions — the durable asset is the state/transition/authorization definition, which ports to Symfony Workflow or a hand-rolled implementation if we walk away. Plan accordingly: vendor or fork the package, pin it, verify compatibility with our Nova version, add integration tests around permitted and forbidden transitions, and confirm whether transition history is persisted before we depend on it for reporting. If the spike shows friction, the fallback is a small in-house field + policy + action set, which is a known quantity.

Recommendation: Conditional go — adopt only as a prototype-to-fork inside an existing Nova deployment, with a named owner and an explicit exit path. Do not use it for customer-facing, high-concurrency, or compliance-sensitive workflows.