Workflow Logger Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on workflow observability. The single most useful output of evaluating this package is a "no" on adoption and a "yes" on a ~1–2 day in-house build. A transition logger is a thin event listener, not a product; paying the dependency cost buys almost nothing.
• Whether workflow history is a feature or an internal tool. The package's scope (log transitions of a state machine) maps directly to two product bets: an end-user-visible activity timeline ("Order #123 moved from Paid to Fulfilling by Jane on 3 Mar") versus internal-only debugging. That's a UX and support-cost decision, not just an engineering one.
• Audit/compliance posture. If the roadmap touches approvals, KYC, payments, refunds, or content publishing, regulators and enterprise buyers will ask "who changed this state, when, and from what?" Deciding to capture from → to → actor → timestamp at the transition layer (rather than reconstructing it later from app logs) is a schema decision that's cheap now and expensive in six months.
• Data model: current-state column vs. append-only history. Logging transitions implies an immutable history table alongside the mutable status field. That choice gates future features — SLA timers, cycle-time analytics, "stuck in state" alerting, backfill-free reporting.
• Prioritizing workflow work on the roadmap. If the team is shipping three or more stateful entities (orders, tickets, onboarding, invoices), the marginal cost of a shared transition-logging convention is near zero and the support savings are real. If there's one, defer.
• Ecosystem fit. This is a Symfony bundle — it registers services through Symfony's DI container and hooks the Symfony Workflow component's events. In a Laravel codebase it is not consumable as-is (Laravel has no bundle kernel; you'd need symfony/framework-bundle wiring that isn't worth importing). The PM decision is therefore "mine the pattern, not the package," and standardize on a Laravel-native equivalent (a model observer or event listener writing to an audit table, optionally with spatie/laravel-activitylog for the read side and a state-machine package such as spatie/laravel-model-states for the transitions themselves).

When to Consider This Package

Consider it only when all of these hold:

• The product is on Symfony (3.x/4.x era), already using symfony/workflow, and needs transition logging this sprint.
• Requirements are genuinely minimal: log the transition name, the subject, and the from/to places, into Monolog. No actor attribution, no queryable history table, no retention policy, no PII redaction, no multi-tenancy.
• You're comfortable reading ~200 lines of 2018-era code and vendoring it into your own repo rather than taking it as a Composer dependency.

Look elsewhere — or build — when any of these are true:

• You're on Laravel. Hard stop. Wrong ecosystem; you'd be fighting the framework to get a listener registered.
• Maintenance risk matters. Last release 2018-02-19, 1 star, 0 dependents on the registry. That's not "niche," that's "no evidence anyone runs this in production." No security patching, no compatibility with modern PHP/Symfony, no one to escalate to.
• You need the log to be queryable. Monolog lines are fine for forensics, terrible for "show me every order that bounced back to Pending this week." The moment a PM wants a dashboard, you need a table, and this package doesn't give you one.
• You need actor/context. Who did it, from which surface (API, admin, cron), with what reason code, correlated to a request or job ID.
• You need it to survive refactors. Transition names and place names change; a logging layer with no schema and no versioning becomes noise within two quarters.
• Compliance scope applies (GDPR erasure, SOX-style retention, financial audit). Those need designed retention and redaction, not a logger.

Default recommendation: treat this repo as a specification of what to record, not a dependency. Copy the event surface (which workflow events to hook, which fields to capture, how to avoid double-logging on guard failures) into a first-party listener.

How to Pitch It (Stakeholders)

To executives: We evaluated a small open-source add-on for logging workflow/state changes. It's a Symfony component last released in 2018 with a single star and no downstream users — not something we should put in the dependency tree. But it clarified a genuinely valuable capability: a durable record of every state transition, with who did it and when. We recommend a short first-party build instead: roughly one to two engineering days, no licensing cost, no vendor risk, and it directly de-risks audit questions and cuts "why is this stuck?" support tickets. It also unlocks a customer-facing activity timeline later at near-zero incremental cost. Recommendation: decline the dependency, fund the small build, scope it to the two or three highest-traffic stateful entities first.

To engineering: Don't add fintem/workflow-logger-bundle — it's a Symfony bundle with no releases since Feb 2018, one star, zero dependents, and it won't wire into Laravel anyway. What we want is the pattern: subscribe to state-transition events, write an append-only row per transition (entity_type, entity_id, from_state, to_state, actor_id, source, occurred_at, metadata), fail-open so logging never blocks the transaction, and index on (entity_type, entity_id, occurred_at) for the timeline read. Keep it behind an interface so we can swap storage. Ship it as a shared package in the monorepo rather than per-service copy-paste. Flag: if any team is already on Symfony Workflow, this repo is still worth ten minutes as a reference for which events to hook and how to avoid duplicate entries on guarded transitions — read it, don't require it.