Filament Flow Builder Laravel Package

Product Decisions This Supports

Build vs. buy for internal workflow features. Any roadmap item that sounds like "approvals," "sign-off," "multi-step review," or "request intake" is usually scoped as a bespoke feature and quietly costs 4–8 weeks plus permanent maintenance. This package reframes that decision: the engine (step progression, condition skipping, parallel approvals, request-changes, resume-after-return) is bought for free under MIT, while the domain (which step types exist and what they do) stays in your codebase. That is a favourable split for a PM — you keep the product-defining logic and outsource the state machine.

Concrete feature bets it unlocks. Purchase requests, expense approvals, content review pipelines, onboarding checklists, contract sign-off, access requests, editorial or compliance gating — anything where a record moves through named stages with a decision at each. The shipped purchase-request example (approvers, history, reminders, stuck-flow retry) is close enough to most internal-tool briefs to serve as a credible spike, not just a demo.

Roadmap timing and sequencing. This is v0.1.0 against Filament v5 / Laravel 13 / PHP 8.3+. Those are aggressive version floors, which tells you the author is targeting greenfield panels rather than your existing estate. If you are already on Filament v5, this can be pulled forward into an in-progress epic; if you are on v3 or v4, adopting this package is an upgrade project and should be planned as one, not smuggled into a feature ticket.

Panel and surface strategy. Support for FlowBuilderField (embed in a resource form) and the InteractsWithFlowBuilder trait (bring your own page) means you do not have to decide today whether flow design is an admin-settings concern or a first-class product surface. That keeps an expensive UX question open longer, which is usually the right call pre-validation.

Data ownership and platform decisions. "The package owns no tables" is the single most important line for a PM. Flow JSON and runner position live on your own models, so flows are exportable, queryable, backup-covered by your existing policies, and removable if you churn. It also means no vendor-shaped tables leaking into your analytics schema or your GDPR/data-retention story — worth flagging early to whoever owns data governance.

Localisation as a market decision. English, Traditional Chinese and Simplified Chinese ship in the box. If an APAC rollout or a bilingual internal tool is anywhere on the roadmap, that is a real cost avoided and a signal about the author's target market — worth weighing if you need EU languages, where you would be publishing and maintaining translations yourself.

Instrumentation and audit. The event set (StepReached, StepSkipped, OutcomeChosen, FlowReturned, FlowFinished) is exactly the seam you need for notifications, audit trails and status sync without forking the package. A PM should treat these five events as the analytics contract: decide now what you will log, because it determines whether you can later answer "where do approvals stall?" — the question every stakeholder asks in month two.

Explicitly out of scope — do not put these on the roadmap assuming the package covers them. It is a card-based list builder, not a canvas/BPMN graph editor. There is no built-in SLA timer, escalation, delegation or out-of-office handling (the example hand-rolls reminders and stuck-flow retry, which is a pattern to copy, not a feature). No reporting or cycle-time dashboards. No mention of flow versioning for records already in flight — a genuine gap if flows will be edited while live, and one you should treat as your problem to design around.

When to Consider This Package

Reasonable to adopt when:

• The app is already on Filament v5 / Laravel 13 / PHP 8.3+ (or is greenfield and free to be).
• The workflow is approval-shaped and record-centric — a thing moves through stages, people decide, conditions skip stages. If you can draw it as a vertical list of cards, it fits.
• You are willing to define StepType and ConditionType subclasses. That is the design, not a workaround; teams wanting a no-code "product owner configures arbitrary steps at runtime" tool will be disappointed.
• Keeping schema ownership in-house matters — regulated data, existing retention policy, or a plausible future where you swap the engine out.
• Somebody on the team is comfortable owning a small dependency and publishing views/translations when needed.

Look elsewhere when:

• You need a stable API. v0.1.0 is pre-1.0 by definition. Expect breaking changes to StepType, ConditionType and the FlowRunner surface as the author learns from real usage. Pin the version, budget for upgrade work, and do not build a multi-quarter platform on it without a fork-or-fallback plan.
• Vendor risk is unacceptable. A package at 0.1.0 from a single namespace has no bus factor to speak of. If the workflow is revenue-critical or compliance-mandated, either accept that you may end up maintaining a fork or choose a commercially supported engine.
• You need true BPMN, gateways, timers, or a visual graph. Parallel approvals and conditional skips are not a process engine. Anything with timers, event-based gateways or long-running sagas belongs to a different class of tool.
• You need configurable-at-runtime steps by non-developers. Code-defined step types deliberately prevent this. If the requirement is "ops changes the workflow without a deploy," this is the wrong trade.
• You need flow versioning and in-flight migration. Not described in the release. Assume you build it.
• You are not on Filament. The builder is a Filament field/trait; the value proposition collapses outside that ecosystem.
• You need a large hiring pool and Stack Overflow coverage. Pre-1.0 niche packages have neither; onboarding cost lands on whoever reads the source.

Adoption posture worth recommending: treat it as a time-boxed spike on one real, low-stakes workflow (the purchase-request shape), measure how much of your StepType set is genuinely bespoke, and only then commit. The MIT licence and zero-schema footprint make the exit cheap, which is precisely what makes an early trial defensible.

How to Pitch It (Stakeholders)

For executives — one paragraph. Approval and sign-off features keep appearing on the roadmap under different names, and each one is currently a multi-week bespoke build plus permanent maintenance. This package provides the generic engine — step progression, conditional skipping, parallel and partial approvals, request-changes and resume — as MIT-licensed open source, so we would pay only for the parts that are actually specific to our business. It adds no tables to our database, so our data, backups and reporting stay ours and the decision is reversible. The trade-off is maturity: it is a first release (v0.1.0) tied to the newest Filament and Laravel versions, so I would recommend a bounded trial on one internal workflow rather than a platform commitment.

For engineering — the honest framing. The seams are in the right places: StepType/ConditionType for domain logic, a FlowRunner that emits lifecycle events rather than hard-coding side effects, a form field or a page trait so we are not forced into one UX, and no schema ownership so there is no migration debt. That is a design we would plausibly arrive at ourselves. What we would be taking on is a pre-1.0 dependency: pin it, expect breaking changes, read the source before trusting it, and be prepared to vendor a fork. Effort to evaluate is small — clone it, run the purchase-request example, reimplement one of our existing approval flows in a branch, and report back on the size of the StepType surface we need.

For the design/ops stakeholders. Users get a card-based builder inside the admin panel they already use — steps in order, conditions that skip a step, approvers set to any/all/a count, and a "request changes" path back to the submitter. It is deliberately not a drag-and-drop flowchart tool: what a step can do is defined by engineering, so users compose workflows from a curated, safe set of steps rather than inventing new ones. Set that expectation early; it prevents the "why can't I add a custom stage?" conversation in week three.

What to ask for. Approval to spend a sprint on a spike against one live internal workflow, with the explicit success criteria: (1) we can express our real approval rules with a small number of step types, (2) the event hooks cover our notification and audit requirements without forking, (3) we are comfortable with the upgrade exposure given our Laravel/Filament versions. If all three hold, the build-vs-buy maths is strongly in favour of adopting.