- How do I install eightynine/filament-approvals in a Laravel Filament application?
- Install it with Composer using composer require eightynine/filament-approvals, then publish the package config and migrations and run php artisan migrate. Register the plugin on your Filament panel provider, add the package trait and interface to each model that needs approvals, and attach the approval actions and table columns to the matching resources. The integration is designed for a greenfield Filament admin, so a pilot should take days rather than weeks.
- Which Laravel and Filament versions does this approvals plugin support?
- Check the composer.json constraints before committing, because the package is built for the TALL stack and inherits Filament's fast release cadence. The expected baseline is PHP 8.1+, Laravel 10 through 12, and Filament 3.x or 4.x, but the exact matrix comes from the package constraints rather than the README. Also confirm that recent releases track Filament majors promptly, since breaking changes to actions, schemas, and table APIs force plugin upgrades.
- Can I run the approval logic outside Filament, for example from an API or queue worker?
- This is the most important thing to verify before adopting: whether approval eligibility, sequencing, and separation-of-duties rules live in a domain service you can call from an API, queue worker, or CLI, or only inside Livewire and Filament actions. If the logic is bound to the panel UI, flows that start or resolve approvals outside Filament, such as a mobile approver screen or one-click email approve, will need a headless service layer you build yourself. Read the source for a contract or service class before you design those paths.
- Does it support multi-step approval chains, parallel approvers, or quorum rules?
- The overview describes routing a record to one or more approvers, so multi-approver flows are in scope to some degree. What is not stated is whether chains are configurable per model as sequential, parallel, quorum, or threshold flows, or whether it is effectively a single-approver flag. Confirm this against your actual sign-off policy before designing around it.
- How does filament-approvals handle concurrent approvals on the same record?
- Approval flows typically fail in the seams: two approvers acting on the same record, reject after approve, reassignment mid-flight, and timeouts. Ask whether the package uses row locking, unique constraints, or optimistic checks, and read the tests that cover those cases. Do not assume correctness here; write your own concurrency tests during the pilot.
- Is the approval history immutable and auditable?
- The package tracks pending, approved, and rejected states with a full history, which is the right foundation for an approval control. If it backs an SOX or ISO-style control, verify that history is append-only and captures actor, timestamp, decision, and comment with no path to silently mutate state. Immutability is rarely a plugin default, so this needs explicit confirmation in code and tests.
- How is authorization enforced for approvers?
- Authorization should run through your Laravel policies and gates so approvers are resolved against your existing role model. Package-internal permission checks that bypass policies are a real integration risk, especially in a multi-role back office. Verify how the package decides who may approve a given record before you wire it into production.
- What happens to approval records when a model is deleted, soft deleted, or restored?
- Model deletion, soft delete, and restore are common sources of orphaned approval records and stale pending states. Confirm whether approval rows are cleaned up, preserved for audit, or left dangling when the parent model is removed. Test the soft delete and restore path explicitly, since a restored record may need its approval state reconciled.
- Does the plugin support multi-tenancy and multiple Filament panels?
- If you run multi-tenant panels, confirm that approval records are scoped per tenant and per panel rather than stored globally. Also check whether the plugin is Octane-safe, meaning no request-scoped static state, and whether the migrations use native enums or JSON columns, since Postgres JSONB behaves differently. These are quick checks that are much cheaper before the pilot than after.
- Is eightynine/filament-approvals production-ready and well maintained?
- The package has roughly 120 stars and no known dependents, and it is maintained by a single author, so there is little third-party production validation. That is a material risk if approvals sit on the critical path of a financial or compliance control, so budget time to read the source, write tests, and possibly fork. If your approval rules must live outside Filament, compare this plugin against building a small internal approval service backed by your own domain layer.