Weave Code
Escalated Filament Laravel Package
escalated-dev/escalated-filament
A Filament v3 admin panel plugin for the Escalated support ticket system. Manage tickets, departments, SLA policies, escalation rules, and macros from your existing Filament panel, powered by escalated-laravel.
Escalated plugin for Filament
Frequently asked questions about Escalated Filament
- What does escalated-dev/escalated-filament actually do?
- It is a Filament plugin wrapper around the escalated-laravel support ticket package. It ships Filament Resources, Pages, Widgets, and Actions for managing tickets, departments, SLA policies, escalation rules, macros, and more from your existing admin panel. It does not duplicate business logic: ticket lifecycle, SLA calculations, and escalation rules all come from the core Laravel package. You install it as a Composer package and register it on a Filament panel.
- Which Laravel and Filament versions does escalated-filament support?
- The README targets Laravel 11.x and Filament v3, and the package depends on escalated-dev/escalated-laravel ^1.9.0. Because the plugin is tightly coupled to the core package, its major version must match the escalated-laravel upgrade you are running. Always check the composer.json constraints and the release notes before bumping either package, since the two are released in tandem.
- How do I install escalated-filament with Composer and register it in my Filament panel?
- Run composer require escalated-dev/escalated-filament, then add the plugin to your panel provider using the plugin() method on the Panel configuration. Database tables, migrations, and config come from escalated-laravel, so publish and run those first. After registering the plugin, verify that the agent and admin gates resolve for your current users before opening the panel to staff.
- Do I need escalated-laravel installed as well, or does the Filament plugin work standalone?
- You need both. escalated-filament is a presentation layer only and requires escalated-dev/escalated-laravel ^1.9.0 as a dependency, since all models, services, migrations, and events live in the core package. The plugin just exposes them inside Filament. That also means a breaking change in the core package (frontend, migrations, private attachments, inbound email) affects the plugin upgrade.
- How do I configure the escalated-agent and escalated-admin gates?
- Gate names default to escalated-agent and escalated-admin, and you can override them via config or by naming the gates passed to the plugin. Each name must resolve through Laravel's Gate, whether defined with Gate::define, Spatie Permission, or Filament Shield. The gates are checked in the Support\PanelAccess class, so make the naming decision explicitly rather than assuming your existing roles map one to one.
- Why did my support staff lose access to Escalated resources after upgrading to 1.4.0?
- Version 1.4.0 is a security fix: agentGate() and adminGate() were documented but never actually read, so every earlier release exposed tickets, webhooks, API tokens, roles, macros, settings, and reports to any user who could log into the panel. Now anyone who does not pass the configured gate receives a 403 and the Escalated navigation disappears entirely. Because the nav silently vanishes, it looks like a broken panel rather than a missing permission, so audit your gate coverage before and after upgrading.
- Does escalated-filament work with Spatie Permission or Filament Shield roles?
- Yes, but the mapping is a deliberate decision rather than an automatic one. Because gate names are configurable, you can point escalated-agent and escalated-admin at gates backed by Spatie permissions or Filament Shield roles. Remember that authorization is additive: effective access is the gate AND your model policies AND, in tenant mode, a tenant-local seat. Policies that previously masked the missing gate will no longer grant access on their own.
- Does the plugin support multi-tenancy and tenant-local staff seats?
- Yes, and tenancy requires more than a global agent or admin flag. With tenancy enabled you also need a tenant-local seat resolved through TenantResolver::isAgent or isAdmin. Hosts that granted access purely through global roles will silently lose per-account access after upgrading. Plan to backfill seats before deploying, because pickers such as the API token user list and the skill agent picker only show seated agents.
- Are gate checks applied in queued jobs, webhooks, and automations?
- Gate checks can run outside an HTTP request context when automations, webhooks, or queued jobs resolve a panel user identity, and this scenario is not addressed in the release notes. It is the most likely source of post-deploy runtime failures. Test any non-interactive code path that touches Escalated models or resources in staging. If a job resolves a staff member without a seat or gate, expect it to fail where it previously succeeded.
- How should I test and audit before upgrading escalated-filament from 1.3.x to 1.4.x in production?
- Treat 1.3.x as having a live authorization gap and run an audit query first: list every current Escalated user and confirm each resolves to escalated-agent or escalated-admin. Then plan the plugin bump as one change window with the escalated-laravel 1.9 upgrade, since that release carries its own breaking changes. Verify in staging with real role and tenant combinations, check the seat-dependent pickers for empty results, and exercise queued jobs and webhooks. Integration itself is just a Composer bump plus a config check; the effort is the authorization audit.
Weaver
How can I help you explore Laravel packages today?