Workflower Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for stateful domains. Any roadmap item whose core is "things move through stages" is a candidate: order fulfillment, subscription and billing lifecycles, KYC/onboarding, content review and publishing, support ticket escalation, claims adjudication. A place/transition model forces the team to name every state and every legal move, which turns vague feature requests into a reviewable graph.
• Build vs. buy vs. borrow. The honest framing here is "borrow": BSD-2 code that hands you workflow primitives plus Symfony DI wiring instead of a homegrown state machine. The real decision is not library vs. no library — it is in-app, self-hosted, framework-native workflow versus workflow-as-a-service (Temporal, Camunda, Step Functions). This package anchors the far end of the self-hosted spectrum.
• Make vs. maintain. With zero dependents and a release history that stalled after September 2017, adopting it is functionally a decision to fork and own a small codebase. The 1.4.0 release softens the "no upstream fixes ever" line but does not change the ownership math: one maintenance commit is not a support commitment. That is a staffing and ownership call, not a procurement call, and it belongs in the roadmap conversation, not the dependency list.
• How configurable workflow should be in v1. This package pushes you toward developer-defined workflow definitions shipped with the code. If the roadmap includes "ops can edit the workflow without a deploy," that is a different class of product and a different class of engine — decide now, because it constrains the choice.
• Who is allowed to move a thing, not just whether it can move. The renewed Security Participant means transitions can be guarded by the framework's permission system rather than by ad-hoc controller checks — "only a compliance officer can approve," "a requester cannot self-close a ticket." That is a product policy question that should be answered explicitly, and this release is the first version of the package where the answer lives in the workflow definition instead of scattered across controllers.
• Auditability and compliance posture. Explicit transitions give you a defensible answer to "who moved this to Approved and when," which is often a hard requirement in fintech, healthcare, and enterprise sales cycles. That is a product commitment that should be made deliberately rather than emerging from wherever status strings happen to be written.

When to Consider This Package

Consider it when:

• You are on a Symfony 2.x/3.x/4.x-era codebase and adopting Symfony's own Workflow component would force a framework upgrade you cannot schedule this quarter. Note that 1.4.0's move to AccessDecisionManagerInterface is itself a Symfony 3.4/4.4-era API — deprecated in 5.4 and removed in 6.0 — so this release confirms rather than widens the package's legacy positioning.
• The domain is a bounded state machine — roughly fifteen states or fewer — where a graph definition and the ability to render or export it has genuine onboarding and audit value.
• You need role- or permission-gated transitions and want them declared alongside the graph rather than enforced in controllers. This is the one genuinely new capability in 1.4.0 and the strongest remaining reason to prefer it over a hand-rolled state machine.
• Workflow logic is developer-owned and changes ride the normal release train, not a runtime admin UI.
• You have a named PHP owner who will vendor the fork, pin it, and write tests around guards and transition side effects.
• The alternative on the table is a ninth ad-hoc status column, not a managed workflow platform.

Look elsewhere when:

• The project is greenfield or already on Symfony 5.4+. The core Workflow component covers the same place/transition semantics with events, guards, and Doctrine integration, and it is maintained — and 1.4.0's reliance on AccessDecisionManagerInterface means this bundle will not cleanly serve a modern Symfony security stack. There is no case for taking on this dependency.
• You are building forward on Symfony 6+. The security integration this release modernizes is the same API that platform removed.
• The process is long-running, distributed, retry-heavy, or needs timers and human tasks spanning days — that is Temporal or Camunda territory, not a bundle.
• Procurement or security review gates thinly maintained dependencies. A single maintenance release after a multi-year gap, roughly two dozen stars, and zero downstream dependents still means no Stack Overflow corpus and no predictable upstream cadence; assume you are the maintainer on day one.
• You need multi-tenant or customer-editable workflows.
• The team lacks PHP/Symfony depth to own a fork comfortably.

How to Pitch It (Stakeholders)

For executives: This is a small, permissively licensed (BSD-2) Symfony bundle that replaces scattered status columns with a formal workflow model, and its new release adds permission-checked transitions so policy like "only compliance can approve" is enforced by the engine rather than by whoever wrote the controller. The caveat is still decisive: before this release it had not shipped since September 2017, it has roughly two dozen GitHub stars and zero downstream dependents, and one maintenance commit is not a support commitment. The real ask is not "adopt a library" but "fund a small fork and own it" — and my recommendation remains to decline that for anything new. It is worth a few days of evaluation only where we already run an older Symfony version and want consistent, permission-gated state handling without a framework upgrade. This is a one-service experiment, not a platform bet, and the expected downside is bounded to that experiment.

For engineering: It is a Symfony bundle wrapping Workflower's place/transition engine and registering it with the DI container. Version 1.4.0 rebuilds the Security Participant around AccessDecisionManagerInterface instead of RoleHierarchyVoter, which means transition guards can consult the access decision manager for the current token — cleaner than voter juggling, and the right call for a 3.4/4.4-era codebase. Two things to weigh: that interface is itself deprecated in Symfony 5.4 and gone in 6.0, so this release lands the package firmly in maintenance-for-legacy territory rather than modernizing it; and one commit from a single contributor is not a sign of revived stewardship. If we do adopt, scope it to one bounded context, vendor the fork in our monorepo, pin the version, cover guards and transition side effects with tests, and write down the exit path before the first commit. Treat it as a stopgap for legacy code, not a foundation.