- How do I install the laravel-service-desk package?
- Install it with Composer using composer require jeffersongoncalves/laravel-service-desk, then publish the package's migrations and configuration and run php artisan migrate. Because the package is headless, installation gives you Eloquent models, database tables, and workflow services rather than routes or screens. Check the repository README for the exact publish tags and any required queue, mail, or scheduler configuration before rolling it out beyond a local environment.
- Which PHP, Laravel, and database versions does laravel-service-desk support?
- Supported versions are not spelled out in the package overview, so inspect the composer.json require block and any CI matrix in the repository before adopting it. Constraint ranges there are the authoritative answer for PHP, Laravel, and illuminate component versions. Database support depends on the shipped migrations, so verify your target engine, especially if you plan to use the shared-connection mode across multiple applications.
- Does laravel-service-desk include an admin UI or dashboard?
- No. The package is explicitly headless: it ships models, migrations, and workflow tooling, but no admin UX, screens, or reporting layer. You are expected to build your own admin panel with something like Filament, Inertia, or a separate front end, or to consume the package through a JSON API. If you need a turnkey helpdesk out of the box, this package will feel incomplete.
- How does SLA tracking work in this Laravel ticketing package?
- The package includes SLA tracking as part of its ticket domain, so SLA policies can be attached to tickets and used to drive response and resolution expectations. Specific semantics such as business-calendar handling and time zone behavior are not documented in the overview, so review the source and write tests against your own working-hours assumptions. For production use, confirm exactly how SLA deadlines are calculated and whether breach detection runs in the scheduler or on demand.
- What are the ticket sharing strategies in laravel-service-desk?
- Version 1.2.0 exposes three transports: database, api, and shared-connection. Database mode suits a single monolith, api mode suits a central service-desk service consumed by satellite Laravel apps, and shared-connection mode suits a family of apps co-located on one database. The api transport is the safer default because it keeps a network contract rather than a schema contract, while shared-connection introduces cross-application schema coupling and coordinated migration obligations.
- How do satellite Laravel apps integrate with the service desk over the API?
- Satellite apps use the ApiTicketTransport together with the package's signed-request middleware, and resources are keyed by UUID in the responses. Discovery endpoints such as GET departments and GET departments/{id}/categories let remote apps resolve catalog IDs dynamically instead of hardcoding foreign keys that break when the catalog changes. Before production, review how the middleware handles replay protection, clock skew, and key rotation.
- Can a satellite app add comments to a ticket through the API?
- Yes. ApiTicketTransport::addComment() posts to tickets/{uuid}/comments, which lets remote apps participate in the conversation loop without touching the database. Internal notes are intentionally unreachable through this transport, so the security boundary lives in the transport rather than in caller discipline. Confirm server-side how comment author identity is established and whether a satellite could spoof a commenter.
- Does laravel-service-desk handle users, teams, roles, and multi-tenancy?
- The package models agents and ticket assignment, but tenant, user, team, and permission modeling are not described as owned concerns, so you should expect to bring your own authentication and authorization layer. Plan on mapping your application's users to assigned agents and scoping queries yourself. If you need strict multi-tenancy, verify how global scopes interact with the UsesServiceDeskConnection trait before relying on it.
- Is laravel-service-desk production-ready?
- Treat it as promising but not yet a platform commitment. The maintainer count, star count, and dependent count are all low, the bus factor is one, and there is no package-owned notification or reporting layer to fall back on. A sensible approach is a time-boxed spike plus a security review of the transport and signed-request layer, with a fork or maintenance contingency in place before it becomes production-critical.
- What are alternatives to laravel-service-desk?
- Alternatives include building ticketing directly on Eloquent and your own queues, adopting a dedicated self-hosted helpdesk such as Zammad or osTicket, or using a commercial SaaS ticketing API. Choose this package when you want a Laravel-native domain model with migrations, SLA concepts, and a defined integration contract that you can extend yourself. Choose an external helpdesk when you need an admin UI, reporting, and notifications without building them.