Workflow
Controlled status transitions
Ticket status changes are handled through dedicated workflow logic. Invalid transitions are rejected instead of allowing arbitrary status updates throughout the application.
← Back to projects
Production Project
Service Desk
A production-ready service management application built with Laravel, focused on structured ticket workflows, permissions, integrations, automation and maintainable backend architecture.
Type
Service management platform
Focus
Backend architecture & integrations
Status
Completed
01 / The Project
The Project
Service Desk is a backend-focused support management application designed around a structured ticket lifecycle and clearly separated user responsibilities.
The application supports three main roles: Requester, Agent and Administrator. Each role has its own permissions and responsibilities within the ticket workflow.
Requesters can create and follow their tickets, agents can work with assigned requests and manage their progress, while administrators have broader control over users, assignments and system-level operations.
The project was designed as a realistic production application rather than a simple CRUD system. The main focus was predictable business rules, maintainable backend code, traceable changes, integrations and reliable behaviour when application state changes.
02 / Core Backend
Core Backend
The core of the application is built around explicit ticket workflow rules instead of allowing arbitrary state changes directly from controllers or models.
Authorization
Role-based permissions
Laravel policies define what Requesters, Agents and Administrators are allowed to do with tickets, comments, attachments and workflow operations.
Application logic
Service-oriented design
Business operations such as workflow transitions, notifications and external integrations are separated into dedicated services, keeping controllers focused on request handling.
Consistency
Database transactions
Operations that update multiple parts of the application state are executed inside database transactions so related changes succeed or fail together.
Domain structure
Enums and explicit states
Ticket statuses and priorities are represented by PHP enums, reducing scattered string values and making domain rules easier to understand and maintain.
Assignment
Ticket ownership
Tickets can be assigned to agents while preserving the original requester relationship, allowing the application to distinguish clearly between ticket ownership and ticket handling.
03 / Audit & Notifications
Audit & Notifications
Important ticket actions are traceable, while notifications are handled outside the main request flow so business operations remain reliable and responsive.
Audit trail
Human-readable ticket history
Ticket changes are recorded in a dedicated history layer, preserving who performed an action, when it happened and what changed.
Instead of exposing raw database values to users, the application converts stored changes into readable history entries for events such as status changes, assignments and priority updates.
Examples
/
Status changed from New to In Progress
/
Ticket assigned to an agent
/
Priority updated from Medium to High
Collaboration
Comments
Users can discuss ticket progress directly inside the application while keeping communication associated with the correct ticket and user.
Files
Private attachments
Ticket attachments are stored privately and accessed through application authorization rather than being exposed as unrestricted public files.
Notifications
Queued delivery
Notifications are dispatched through the queue so external delivery does not block the main user request.
Reliability
After-commit side effects
Side effects that depend on persisted application state are triggered only after the database transaction has committed, preventing notifications from being sent for changes that were later rolled back.
04 / Integrations
Integrations
External systems are integrated through dedicated application services and verified inbound endpoints, keeping provider-specific behaviour separated from the core ticket domain.
API
REST API
The application exposes a REST API for working with service desk data outside the Blade interface while reusing the same authorization and business rules as the main application.
Jira
Jira integration
Service Desk can communicate with Jira through a dedicated integration layer, allowing external issue tracking to be connected without placing Jira-specific logic inside the core ticket workflow.
GitHub
GitHub integration
GitHub integration allows repository-related events and external development workflows to interact with the application through a provider-specific service instead of coupling them directly to ticket models and controllers.
Webhooks
Verified inbound events
Incoming webhook requests are verified before their payload is accepted, preventing untrusted requests from being treated as legitimate provider events.
Reliability
Idempotent processing
Webhook processing is designed to tolerate duplicate deliveries. Repeated provider events can be recognized so the same external event does not create duplicate application changes.
Architecture
Provider isolation
External providers are kept behind dedicated integration boundaries. This keeps the application domain independent and makes provider-specific behaviour easier to replace, test and extend.
05 / AI Integration
AI Integration
AI functionality is integrated as an application capability, not embedded directly into ticket controllers or tied permanently to a single external model provider.
The implementation keeps AI-generated suggestions under user control. Generated output can assist the workflow, but application state is not changed automatically without explicit human action.
Architecture
Provider-neutral design
AI functionality is exposed through an application-level abstraction instead of spreading provider SDK calls throughout the codebase. The rest of the application depends on a common interface rather than one specific AI vendor.
Providers
OpenAI and Groq
The integration supports multiple AI providers, including OpenAI and Groq. Provider selection can change without requiring the ticket domain itself to understand provider-specific APIs.
Workflow
Human-in-the-loop
AI output is treated as a suggestion rather than an authoritative system decision. Users review generated content before deciding whether it should become part of the actual ticket workflow.
Separation
AI outside the core domain
Ticket workflow rules remain deterministic and independent from AI availability. If an AI provider is unavailable, the core service desk workflow can continue to operate normally.
Design principle
AI assists the user. It does not silently become the business logic.
06 / Testing & Reliability
Testing & Reliability
Automated tests protect the application workflow, authorization rules and integrations so changes can be made without relying only on manual verification.
Tests
315
automated tests
Assertions
979
assertions
Pipeline
CI
automated validation
PHPUnit
Feature and unit tests
Automated tests verify business behaviour at different levels, including individual domain rules and complete application workflows.
Integrations
External behaviour verification
Integration-related behaviour is tested without requiring every test to depend on live third-party services, keeping the test suite repeatable and suitable for automated execution.
CI
Automated project validation
The CI pipeline runs automated checks before changes are accepted, providing an additional safety layer beyond local development and manual review.
Code quality
Laravel Pint
Laravel Pint is used as part of project validation to keep PHP formatting consistent across the codebase.
Build
Production asset validation
The frontend production build is verified alongside backend checks so deployment does not depend on development-only asset behaviour.
Final verification
315 tests, 979 assertions, Laravel Pint, production asset build and CI validation completed successfully.
07 / Production & Deployment
Production & Deployment
The application is deployed as a real production system with persistent storage, background processing, HTTPS and external email delivery.
Hosting
Railway deployment
The application is deployed on Railway with separate application and background worker processes.
Database
MySQL
Production application data is stored in MySQL, with migrations used to keep database structure consistent between environments.
Background jobs
Dedicated queue worker
Queued jobs run in a dedicated worker process so notifications and other asynchronous operations are handled independently from web requests.
Storage
Persistent private files
Private ticket attachments are stored on persistent storage so uploaded files survive application redeployments while remaining protected by application authorization.
Security
HTTPS and secure cookies
The production environment uses HTTPS with a custom domain and secure cookie configuration appropriate for encrypted browser sessions.
Health
Application health endpoint
Laravel's health endpoint is available for basic deployment and availability checks.
Resend delivery
Transactional application email is delivered through Resend using the project's configured production sender.
Domain
desk.kotov.lt
The application is available through a dedicated custom subdomain, providing a real public deployment rather than only a local demonstration environment.
Production setup
Railway, MySQL, dedicated queue worker, persistent private storage, HTTPS, health checks and transactional email delivery.
08 / Technology Stack
Technology Stack
The project combines a conventional Laravel application stack with background processing, external integrations and production-focused tooling.
Backend
PHP
Laravel
REST API
Laravel Sanctum
Data
MySQL
Eloquent ORM
Database migrations
Private file storage
Integrations
Jira
GitHub
OpenAI
Groq
Resend
Engineering
PHPUnit
Laravel Pint
Docker
Laravel Sail
CI
09 / Result
What This Project Demonstrates
Service Desk demonstrates the ability to design and maintain backend functionality beyond basic CRUD operations, with clear business rules, authorization, asynchronous processing, integrations and production deployment.
The project also focuses on concerns that become important in real applications: transactional consistency, auditability, duplicate external events, private file access, automated tests and failure isolation between application components.
Structured business workflows
Role-based authorization
Service-oriented backend architecture
Reliable external integrations
Automated testing and CI
Production deployment and operations