Weave Code
Filament Flow Laravel Package
packstub/filament-flow
Filament Flow is a Laravel Filament package for defining and managing multi-step workflows directly in your admin panel. Build, visualize, and track flows for approvals, pipelines, and status-driven records in a clean, integrated UI.
Visual workflow automations for Filament panels: triggers, conditions and actions drawn on a canvas, run by your queue.
Frequently asked questions about Filament Flow
- What is packstub/filament-flow and what does it do?
- Packstub/filament-flow is a Filament panel plugin for building visual workflow automations inside a Laravel admin panel. You draw triggers, conditions, and actions on a canvas, then runs execute through your queue. It adds a WorkflowResource, a runs relation manager, a FlowBuilder form field, and a node configuration slide-over to Filament. It is best treated as internal-ops automation glue rather than a standalone workflow service.
- How do I install filament-flow in a Laravel Filament panel?
- Install it with composer require packstub/filament-flow, then publish the package config and the migration stub, run php artisan migrate, and register the plugin on your Filament panel. Finish by running php artisan filament:assets so the prebuilt flow.js and flow.css assets are available. No bun, Vite, or Tailwind build is required unless you fork and modify the canvas. Check the repository's install notes for the exact provider and plugin registration snippets.
- Which Laravel, PHP, and Filament versions does filament-flow support?
- The package advertises support for Filament v4 and v5 panels, so confirm the exact Laravel and PHP constraints in its composer.json before installing. The optional Ask AI node depends on packstub/agents as a dev dependency and requires PHP 8.4. Dual Filament major support means you should pin versions and re-test after any panel upgrade.
- Does filament-flow require a queue worker?
- Yes for any workflow that uses Wait steps, because Wait always depends on the queue; other runs are described as executing optionally through the queue. Treat a healthy, delay-tolerant worker pool as a hard runtime dependency for production automations. Validate retry, backoff, timeout, and failed-job behavior before relying on flows with external side effects. A sync queue may be fine for simple local tests but will not exercise delayed Wait behavior.
- Can I create workflows programmatically or add custom node types?
- Yes. The internals separate Dispatcher, Graph, and Runner under src/Engine, and src/Nodes exposes Trigger, Action, and Condition base classes plus built-in nodes. You can define domain automations in code and extend the system with custom node classes without using the canvas. Treat the custom-node API as something to verify against the package source before committing, since the evaluation does not confirm it as a stable public contract.
- Can external systems trigger a flow via webhook, and how is the webhook secured?
- The package includes an Http/Controllers/WebhookController as an external ingress point, so flows are not limited to UI-created runs. The provided documentation does not establish signature verification, shared-secret authentication, or replay protection. Do not expose the webhook endpoint publicly until you add your own authentication middleware and replay safeguards. Test the endpoint's authorization behavior in staging before production use.
- Do workflow edits affect runs that are already in progress?
- There is no evidence in the package assessment that a run pins the graph version it started on. That means editing a workflow may change behavior for runs already in flight, which is risky for approvals and multi-step side effects. If in-flight consistency matters, capture the graph definition on the run record or snapshot it before execution. Confirm the actual behavior in the source before designing around it.
- Is filament-flow a BPM platform, and what alternatives should I consider?
- No. It is a workflow builder inside Filament, not a BPM-grade platform, and the evaluation found no graph versioning for in-flight runs, SLA or escalation semantics, human-task assignment, or multi-tenancy. Position it for internal-ops automation, approvals, pipelines, and status-driven records where Filament is already the admin surface. If you need guaranteed SLAs, assigned human tasks, or tenant isolation, compare dedicated BPM or workflow services and custom Filament actions before adopting this package.
- Do I need Vite, Tailwind, or Svelte to use the flow builder?
- No, the frontend ships prebuilt as resources/dist/flow.js and flow.css registered through FilamentAsset, so consuming teams do not need bun, Vite, or Tailwind unless they fork the canvas. The canvas itself is built with Svelte 5, @xyflow/svelte, Tailwind v4, and Vite, which matters if you customize it. Tailwind v4 inside a Filament panel carries styling-collision risk, and upgrade notes call for rebuilding the stylesheet and running php artisan filament:assets.
- What should I verify before relying on filament-flow in production?
- Verify queue health, retry and backoff semantics, timeout behavior, and idempotency for any action with external side effects. Confirm whether run records are pruned by a shipped command or whether retention is your responsibility, and test webhook authentication plus replay protection. Because the ecosystem is thin at roughly 20 stars and zero dependents, plan for MIT-licensed fork maintenance rather than commercial support. Exercise Wait steps with a real delay-capable queue and test upgrades against both Filament v4 and v5 if you support both.
Weaver
How can I help you explore Laravel packages today?