Laravel Flows Laravel Package

Product Decisions This Supports

• Build vs. buy for workflow orchestration. laravel-flows lets us model multi-step business processes — checkout, onboarding, approvals, staged imports — as first-class, version-controlled classes instead of ad-hoc service spaghetti, without buying Temporal, a BPM suite, or a SaaS orchestrator. For most Laravel shops this is the pragmatic middle path: it formalizes the action/service pattern the team already writes by hand rather than adding a new runtime, so the real comparison isn't "package vs. orchestrator," it's "package vs. our own bespoke orchestration code we'd build and maintain anyway." That framing is usually where the ROI shows up.
• Feature scoping and shared enablers. Transaction boundaries and step-level validation (the substance of 1.0.4) map directly onto user-facing features we already have on the roadmap: multi-step forms, approval gates, import pipelines. Instead of re-solving rollback and input handling per feature, we schedule this once as an enabler and reuse it. That converts recurring per-feature engineering cost into a one-time adoption cost.
• Roadmap sequencing signal. If the next two or three quarters contain wizards, onboarding sequences, fulfillment pipelines, or import/export jobs, adopting now front-loads a reusable pattern and pays off quickly. If the roadmap is mostly single-step CRUD, the leverage is thin — defer and revisit when a genuine multi-step process lands.
• Explicit "no" list protects scope. Declining distributed sagas, durable timers, human-task queues with SLAs, and visual orchestration dashboards keeps the bet contained and stops the package from being over-sold internally as something it isn't.
• Cheap pilot, reversible decision. Adoption is composer-installable, migration-free, and can be scoped to a single low-risk workflow behind a feature flag. That makes this a decision we can make before we have a large body of evidence, because the cost of being wrong is small and the cost of waiting is duplicated workflow code across the roadmap.
• Maturity signal worth tracking. Generics/type improvements and transaction support show the package is converging on production-grade concerns rather than stagnating. Modest, but it's the sort of trajectory that justifies standardizing an internal pattern on it — provided we keep the internal wrapper so the choice stays reversible.

When to Consider This Package

Consider adopting when:

• We're on Laravel and already lean on its transactions, validation, and queues — this composes existing primitives rather than replacing them.
• Workflows are in-process, synchronous or queue-backed, and confined to our application — not spanning services.
• We want workflows as code in version control, reviewed like any other code, and easily unit-tested step by step — not configuration in a visual builder.
• A roadmap item needs atomic multi-step writes or consistent validation at step boundaries. These are exactly what 1.0.4 targets, and exactly what teams usually hand-roll badly.
• The team is small enough that a focused community package beats operating orchestration infrastructure.

Look elsewhere when:

• We need durable execution, cross-service sagas, compensating transactions across systems, or long-running timers. That's Temporal, Laravel Workflow, or a broker-based design — not this.
• We need vendor SLAs, enterprise support, or a broad contributor base. This is a single-maintainer package; bus-factor risk is real and must be an explicit, recorded accepted risk rather than an unspoken one.
• Workflows are primarily human tasks with SLAs and escalation — a BPM or ticketing integration fits better.
• We need run history, replay, or observability dashboards out of the box. We'd build or bolt those on; budget for it.

Gates before committing:

• Confirm transaction semantics on our actual database and queue driver — specifically partial failure inside a queued flow, and nested-flow/savepoint behavior.
• Treat 1.0.4 as a feature release despite the patch number — transaction boundaries and validation are behavior-affecting. Review PR #5 and the diff before pinning anywhere near production, and adopt a "read the diff" upgrade policy rather than trusting semver.
• Confirm PHP/Laravel version support, static-analysis behavior with the generics, and real test coverage.
• Spike one real workflow (checkout or onboarding) and measure code removed, defects caught, and review effort versus a hand-rolled service. That delta is the business case — decide on it, not on the README.

How to Pitch It (Stakeholders)

For executives. We're evaluating laravel-flows, a small Laravel package that expresses multi-step business processes — checkout, onboarding, approvals, imports — as structured, testable code instead of scattered service classes and controller logic. Release 1.0.4 adds transaction support and step-level validation, which directly targets our two most common workflow failure modes: partial writes when a step fails mid-process, and inconsistent input handling between steps. The business case is less custom code and fewer production incidents in multi-step features — not new infrastructure. It's a low-cost, low-lock-in bet: no new runtime, no migrations, no new operational surface, and it can be proven on a single pilot workflow before any broader commitment. The principal risk is maintainer concentration in a single-author package, which we mitigate with version pinning, a named internal owner, an internal abstraction wrapper that keeps the implementation swappable, and an initial rollout confined to one low-risk flow.

For engineering. This is a thin orchestration layer over Laravel's transaction, validation, and queue primitives — no new runtime, no distributed system, no persistence layer. Flows are classes with discrete, container-resolved steps; you get one obvious home for a multi-step process, one entry point, and step-by-step testability. 1.0.4 adds transaction handling inside flows, validation at step boundaries, and better generics/type ergonomics for static analysis and review. Proposed path: pilot one workflow; pin to 1.0.x and review each release rather than auto-upgrading; wrap flow definitions behind our own interface so we can fork or swap; and document failure and rollback semantics before broadening. Concrete conventions to write down on day one: put the transaction at the flow boundary, not per step; use afterCommit for mail, HTTP, and dispatches that can't be rolled back; pick one transaction layer because nested transactions silently degrade to savepoints and can leave a flow that looks successful but is partially committed; and always return the payload from a step, since readonly DTOs make a forgotten return fail quietly. And we should explicitly not use it for cross-service sagas or long-running durable workflows — those stay out of scope and need a different tool.