Filament Flow Laravel Package

Product Decisions This Supports

• Build vs. buy for an in-panel automation surface. The decision is not "workflow engine or nothing" — it is "adopt an MIT-licensed Filament resource with a Svelte Flow canvas, trigger/condition/action node classes, a graph runner, run history, and a webhook controller" versus "spend a quarter building a canvas, a graph model, and a run log before the first automation exists." Frame it internally as buy the 70% that is generic, build the 30% that is our domain.
• Roadmap scoping and sequencing. The package hands you a concrete, priceable MVP shape: workflow list, editor with zoom/pan, node configuration slide-over, runs relation manager, webhook ingress, and Wait steps that always land on the queue. Use it to size the delta between "internal ops automation" (config + custom nodes) and "customer-facing automation product" (adds tenancy, quotas, audit, self-serve authoring). Those are different roadmap lines with different owners, and this package only accelerates the first.
• Feature triage with a shared vocabulary. When sales or support asks for "if this, then that" behavior, the trigger / condition / action model gives you a classification rubric: configuration (a built-in node), custom node (a day of engineering, ours to own), or out of scope (durable orchestration, human task routing, connector marketplace). That rubric converts vague inbound requests into a backlog with cost estimates attached.
• Use-case portfolio selection. Strong first candidates: lead and ticket routing, approval chains, staged notifications, third-party webhook ingestion, enrichment and data sync steps, scheduled follow-ups via Wait. Weak candidates: high-volume event streams, long-running compensated sagas, anything that needs 50+ prebuilt SaaS connectors. Pick the first three automations deliberately — they set the credibility bar for the feature.
• Infrastructure and budget decisions the feature forces. Because execution is queue-first and Wait steps always use the queue, adopting this makes worker capacity, retry/backoff policy, failed-job alerting, and run retention into product-visible requirements. That is a real platform cost line to put in the plan, not a footnote.
• Packaging and exposure decision. Internal admin-only tool = low risk, fast path, no multi-tenancy. Customer-visible feature = the package's advertised scope stops short of per-tenant isolation, quotas, and audit guarantees. Decide which side of that line the first release sits on before the spike ends, because it changes the estimate by multiples.
• Integration strategy: in-panel layer or external iPaaS. The optional Ask AI node and the webhook controller are the seams where you choose to lean in-panel (n8n/Zapier stay out of the architecture) or federate out to an iPaaS for connector breadth. This package supports the former; it does not compete with the latter. Good news for a PM: you can ship the internal-ops half now without foreclosing the iPaaS decision.
• Cost-of-ownership honesty. 20 stars, 0 dependents, a single small vendor org, no support contract, and prebuilt resources/dist assets that require php artisan filament:assets on every upgrade. The PM decision is to budget an internal owner and an upgrade cadence as part of the feature, not as an unstated tax discovered six months later.

When to Consider This Package

Adopt it when most of these hold:

• The automation UI belongs inside an existing Filament v4/v5 admin panel; you are not building a separate automation product with its own front end.
• The first audience is internal operators or a small set of trusted admins — not untrusted end users across many tenants.
• You already run supervised queue workers and can absorb delayed jobs, retries, and a retention job for the runs table.
• Automations are moderate-volume and event-driven (per-record triggers, webhooks), not sustained thousands-per-minute throughput.
• Your team can read PHP and a Svelte 5 canvas and is willing to own a pinned fork if needed.
• You want a forkable MIT starting point more than a supported platform, and you are willing to name an internal maintainer on day one.

Look elsewhere — or scope down hard — when any of these hold:

• You need vendor support, an SLA, or a security review trail you can point auditors at. Zero dependents is an honest maturity signal; budget for the fork.
• You need connector breadth, OAuth app management, or a connector marketplace. That is an iPaaS problem and always will be.
• The surface is customer-facing and multi-tenant, with per-tenant isolation, quota, and audit guarantees the package does not advertise.
• You need durable long-running orchestration with compensation and complex state machines — compare against Temporal-style engines, not this.
• You are not on Filament, or cannot tolerate a committed JS build artifact and an asset-publish step in your release process.
• You cannot get an answer on graph versioning for in-flight runs, or on retry/idempotency semantics for actions with external side effects. Those are gating questions, not nice-to-haves — a mid-graph failure that leaves side effects applied is a product incident, not a bug.

Kill criteria for the spike (agree these upfront): no answer on Filament major-version upgrade policy; no demonstrable behavior when a worker dies mid-run; webhook authentication that cannot be made signature-safe; or a first workflow that cannot be run idempotently without rewriting our action code.

How to Pitch It (Stakeholders)

For executives (one paragraph). We have a recurring ask to let admins automate routine work — routing, approvals, notifications, webhooks — without filing engineering tickets. packstub/filament-flow is an MIT-licensed Filament plugin that already ships the visible product: a drag-and-drop canvas for triggers, conditions, and actions, run history inside the panel, and execution on the queue we already operate. Adopting it converts a multi-month build into an integration and extension effort, and the money we spend goes into our domain nodes rather than into generic canvas plumbing. The trade-off is maturity: it is a young, low-adoption package with no support contract, so we treat it as a forkable foundation with a pinned version and a named internal owner — not as a supported platform. Recommendation: a short, time-boxed spike before any commitment to a customer-visible surface.

For engineering (what it buys us, what to verify). It buys us the graph model (Dispatcher/Graph/Runner), node base classes for Trigger/Action/Condition, queue jobs, a webhook controller, a Filament resource with a Svelte Flow field, and a prebuilt front end — consumable without adding bun/Vite to CI. Before we commit, confirm: the actual Filament/Laravel/PHP CI matrix and upgrade policy; whether a run pins the graph version it started on; retry, backoff, timeout, and idempotency semantics for actions with external side effects; runs-table pruning versus our owning retention; webhook authentication and replay protection; and whether the custom-node API is public and stable. Note the repo's own discipline is better than its stars suggest — Pest, PHPStan level 6, svelte-check, vitest, Playwright e2e, and a clean "nothing to do" upgrade note in v1.6.1 — but that lowers breakage odds, not bus-factor risk.

The ask. A one-to-two week spike: install on a non-critical panel, build one synchronous and one Wait-step workflow end to end, deliberately kill the worker mid-run and observe, and write a half-page risk note covering maturity, maintenance ownership, and queue load. Deliverable is a go/no-go — and if go, an explicit call on whether the first release stays internal-only or becomes a roadmap commitment.