- How do I install jeffersongoncalves/filament-service-desk in a Laravel app?
- Install it with Composer using the branch that matches your Filament version, for example composer require jeffersongoncalves/filament-service-desk:"^3.0" for Filament 5. Publishing the config and translations is optional, and you then register the Admin, Agent and User plugins in their respective panel providers. There are no service container bindings, custom middleware or events to wire up, so a working three-panel skeleton is realistic in about a day.
- Which Filament, Laravel and PHP versions does this plugin support?
- Version 1.x targets Filament 3, PHP 8.1, Laravel 10 and Tailwind 3. Version 2.x targets Filament 4, PHP 8.2, Laravel 11 and Tailwind 4. Version 3.x targets Filament 5, PHP 8.2, Laravel 11.28 or newer and Tailwind 4. Because 3.x pins you to the newest Filament and Livewire majors, adopting it may require a framework upgrade first.
- Do I need to install laravel-service-desk separately?
- Yes. This package is a presentation layer only and depends on jeffersongoncalves/laravel-service-desk, which owns the domain model for tickets, SLAs, departments, knowledge base and the service catalog. Adopting it means adopting two packages from a single maintainer. All business-logic risk lives in the core package, while this one carries only UI risk.
- Can I disable the knowledge base, SLA or service catalog features?
- Yes. The Admin plugin exposes fluent toggles such as knowledgeBase(), sla(), emailChannels() and serviceCatalog(), and each panel accepts a widget array that can be set to an empty array. That lets you phase capability rollout from MVP to GA without forking the package. It is one of the more practical design decisions in the codebase.
- How do I register the Admin, Agent and User panels?
- You add ServiceDeskAdminPlugin, the agent plugin and the user plugin to the plugins() array of the matching Filament panel providers, typically passing a navigationGroup such as 'Service Desk'. Each panel then gets its own resources, navigation and dashboard widgets scoped to that persona. The three-persona split maps directly onto the standard admin, agent and end-user operating model.
- What breaking changes should I expect when upgrading versions?
- The plugin class was renamed from ServiceDeskPlugin to ServiceDeskAdminPlugin, the plugin ID changed, and config keys moved from feature-scoped to panel-scoped. Those breaks shipped in 1.2.0, 2.2.0 and 3.2.0 across the separate branches. Each upgrade requires editing your panel providers and republishing the config, so review the changelog before bumping and avoid loosely pinned constraints.
- How do I configure allowed attachment file types on tickets?
- Attachment handling is configuration-only, with an allowed_extensions setting that resolves to MIME types. Publish the config using php artisan vendor:publish --tag="filament-service-desk-config" and edit the allowed extensions list there. Check that any extension you add maps correctly to a MIME type, since the filter works on MIME values rather than raw extensions.
- Is this package mature enough for production use?
- It is young: a single maintainer, around 18 stars and no dependents, so there is no tutorial or community corpus to fall back on when something breaks. The resource coverage is unusually complete for its age, but the version churn and bleeding-edge Filament 5 coupling mean debugging can be hard to attribute between the plugin, Filament and Livewire. It is reasonable for greenfield projects or internal tools where you can absorb upgrades and vet the code yourself.
- Why do I get duplicate or conflicting URL slugs with multiple panels?
- Multi-panel routing is a known-fragile area in this package, and version 1.0.1 was specifically a fix for duplicate URL slugs caused by folder structure under multi-panel setups. If you rename panels, change slugs or customize routes, re-verify each panel's generated URLs. Treat routing as a regression site when upgrading.
- What does the User panel actually give end users?
- The User panel is built around a service request wizard driven by the service catalog's dynamic form fields, with submissions stored in form_data key-value storage. Those requests flow into the agent queue as tickets that agents pick up, comment on, and resolve. That wizard is typically the slowest piece to build bespoke, so its inclusion is the main time saving for most teams.