Workflow Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt: ruled out for greenfield. This is a decision against adoption. lexik/workflow-bundle is an archived Symfony 2-era bundle, not a Laravel package. If your stack is Laravel, it is not installable in any meaningful sense — it depends on Symfony's bundle/service-container contracts and Symfony2 conventions. The decision this surfaces is "do not spend evaluation cycles here."
• Framework-migration and consolidation planning. The fact that it is archived and has zero dependents is a useful data point when auditing legacy Symfony 2.x estates: any application still declaring this dependency is on an unsupported branch and should be scheduled for migration to symfony/workflow, the first-party component that superseded this bundle's purpose.
• Make-vs-buy for state machines / approval flows. If your roadmap includes order lifecycle, content publishing, KYC/onboarding, or multi-step approval workflows, this package is a category signal, not a candidate: it tells you the need is common enough to have been solved at framework level, which argues for using a maintained first-party workflow engine (or a small in-house state machine) rather than a third-party bundle.
• Roadmap prioritization on technical debt. Any surviving usage is a liability line item — no security patches, no PHP 8+ compatibility guarantees, no maintainer. That competes directly against feature work and should be sized accordingly.
• Vendor-risk scoring for the internal approved-dependency list. With 126 stars, archived status, and a composite score of ~1.85 against an opportunity score of 6.38, this is a textbook "high latent need, dead solution" entry: the problem space is real, the artifact is not viable.

When to Consider This Package

Essentially never for new work. Narrow, largely historical conditions where it enters the conversation:

• You are maintaining an existing Symfony 2.x application that already has this bundle wired into AppKernel and config YAML — in which case the action is a migration plan, not an evaluation. The endpoint is symfony/workflow (native since 2.3) or symfony/workflow + symfony/framework-bundle configuration on a supported version.
• You need a reference implementation for how a workflow was exposed to Symfony's DI container and config tree before the component existed — occasionally useful for understanding legacy code you inherited.
• You are doing due-diligence archaeology on a dependency tree and need to confirm the bundle is dead (archived, no dependents) to justify removal in a PR.

Look elsewhere — decisively — when:

• Your stack is Laravel. There is no Laravel integration; the service provider/container model, config loading, and bundle registration are Symfony-specific. For Laravel, use a maintained state-machine package or a hand-rolled transition guard on top of Eloquent, and treat symfony/workflow as off-limits unless you are already running Symfony components standalone.
• You need supported PHP versions. Archived Symfony 2 bundles routinely fail on PHP 8.x due to removed features and unmaintained transitive constraints. No one is fixing that.
• You need security response, LTS guarantees, or an SLA. Archived means no disclosure channel and no patches.
• You want community support or hiring leverage. Zero dependents and 126 stars means no Stack Overflow corpus, no ecosystem familiarity, and no candidate who has used it recently.
• You need an admin UI, visualization, or audit trail. This bundle is a thin Symfony2 integration; it does not provide the operational surface a product team actually needs.

How to Pitch It (Stakeholders)

Bottom line: we are not adopting this package. We are closing it out.

lexik/workflow-bundle is an archived Symfony 2 bundle — not a Laravel package — last meaningfully aligned with a framework branch that reached end of life years ago. It has 126 GitHub stars and zero dependent packages, which tells us it never became load-bearing for anyone. There is no maintainer, no security process, and no realistic path to PHP 8 compatibility. The MIT license is the only unambiguously good thing about it.

The reason it appeared in our scan is that it scored well on opportunity (6.38) — the underlying problem, modeling multi-step business workflows declaratively, is genuinely valuable and shows up repeatedly in our roadmap conversations around order lifecycle and approval chains. The lesson is not "adopt this"; it is "this need is real and already solved at the framework level." If we pursue workflow modeling, we do it with a maintained first-party engine or a small internal state machine we control — roughly a few days of engineering, with an owner and a support story.

Ask for engineering: confirm no current service depends on this bundle; if one does, scope migration to symfony/workflow as technical debt with a target date. Ask for leadership: treat this as a zero-cost "no" — the only spend is the audit time to prove the dependency is gone. What we are deliberately not doing: investing in a proof of concept, since there is no viable version of this package to prove out.