Filament Workflows Laravel Package

Product Decisions This Supports

• Build vs. buy for internal automation: This package supports buying/adopting a Filament-native workflow engine instead of custom-building admin-configurable triggers, conditions, actions, and audit logs.
• Roadmap for back-office automation: It enables PMs to prioritize operational workflows such as record lifecycle automations, event-driven admin tasks, webhook-based integrations, and approval/notification-style actions without bespoke glue for every use case.
• Admin-facing configurability: The rebuilt Filament 5 builder page supports product decisions around letting operations teams configure workflows from the admin panel while engineering retains control over allowed action classes.
• Auditability and operations visibility: Per-run Workflow Log rows and isolated action failures support decisions to expose workflow history for support, compliance, and troubleshooting.
• Secure integration surface: Token-gated, throttled GET/POST webhook support supports decisions to expose controlled external triggers without opening an unauthenticated endpoint.
• Platform upgrade decision: v5 is a major release aligned to Filament 5, Laravel 12/13, PHP 8.2+, and tomatophp/filament-icons 5. PMs should treat this as a platform-alignment upgrade, not a drop-in patch; the previous code remains on the v3 branch.

When to Consider This Package

Consider adoption when:

• The product is a Laravel 12/13 application using Filament 5 and PHP 8.2+.
• The roadmap includes internal/admin-configurable workflow automation: model created/updated/deleted triggers, event triggers, webhook triggers, conditions, and actions.
• The team wants engineering-defined actions registered via FilamentWorkflows::action([...]) while operations users compose workflows in Filament.
• Auditability matters: each active workflow run writes a Workflow Log row.
• Secure webhook intake is needed with a required FILAMENT_WORKFLOWS_WEBHOOK_TOKEN, constant-time token comparison, log redaction, and throttling.
• The team can follow the action contract: only classes extending Services\Abstracts\Action run, and action failures are logged while remaining actions continue.
• Deployment safety matters: InteractsWithWorkflow is safe before workflow tables are migrated.

Look elsewhere or defer when:

• The application is not on Filament 5, Laravel 12/13, or PHP 8.2+, or cannot absorb the major upgrade from v3.
• The product needs customer-facing, highly complex BPM/orchestration with guarantees beyond the release notes, such as advanced retries, queue orchestration, SLAs, or arbitrary user-authored code execution.
• The team cannot accept code-defined action classes and a deploy step for new actions.
• Webhook token configuration and operational secret management are not feasible.
• The product needs a standalone workflow engine outside the Filament admin surface.

How to Pitch It (Stakeholders)

For executives: This release gives us a Filament-native workflow layer for back-office automation with auditable runs, secure webhook triggers, and a rebuilt admin builder. It reduces custom automation glue and lets operations teams configure supported workflows while engineering controls the allowed actions. The trade-off is a required platform alignment to Filament 5, Laravel 12/13, and PHP 8.2+, so adoption should be sequenced with the platform upgrade.

For engineering: v5 supports Filament 5 and Laravel 12/13, adds model/event/webhook triggers that execute every active workflow’s actions and log each run, implements record and where/is/value trigger conditions, registers action arrays through FilamentWorkflows::action([...]), and keeps InteractsWithWorkflow safe before migrations. Action execution is constrained to Services\Abstracts\Action subclasses, with failures logged and remaining actions continuing. Webhooks require FILAMENT_WORKFLOWS_WEBHOOK_TOKEN, use constant-time comparison, keep the token out of logs, and are throttled. The release also adds Filament 5 builder work, factories, Pest tests, PHPStan, and a Laravel 12/13 CI matrix. Engineering should plan the v3-to-v5 migration and validate action contracts, token setup, logs, and trigger behavior before rollout.