Requests that come from outside the delivery team arrive as tickets, get an owner and a priority, and move through a status flow you define. Because tickets sit next to project work, you can see honestly how much capacity unplanned requests are taking. Nominated ticket agents work the queue, and reporting shows volume, ageing, and resolution time.
- Installs
- Available
- Support
- Vendor Supported
- Trust
- Self-Hosted
Active deployments
Priority response
Your infra, your data
Screenshots
Key Features
Ticket Intake
Incoming requests are logged as tickets in one queue, with the detail needed to act on them. Nothing is lost in somebody's inbox or a corridor conversation.
Priority and Severity
Rank each ticket so the team works on what genuinely matters first, instead of treating every request as equally urgent.
Ticket Ownership
Every ticket has an assignee. Nothing sits unclaimed, and there is always one person who can answer where a request stands.
Custom Ticket Workflow
Route tickets through the statuses your team actually uses. In the self-hosted edition you also control the allowed transitions and who may make them.
Ageing and Response
See how long each ticket has been open. Slow ones surface while there is still time to act, rather than when somebody escalates.
One Workspace With Delivery
Tickets live beside project work rather than in a separate tool. The request and the work that answers it stop being two disconnected records.
Capacity Made Visible
When unplanned requests and planned delivery are in one system, the sprint that looked achievable stops being a surprise halfway through.
Alongside Bug Tracking
Incoming requests and product defects live in the same workspace, so a ticket that turns out to be a bug does not have to be retyped somewhere else.
Ticket Reporting
Report on ticket volume, ageing, and resolution time. That is the evidence you need when you argue for more capacity.
Role-Based Access
Ticket access follows your existing Orangescrum roles and permissions, so you are not maintaining a second, separate access model.
Company-Scoped Data
Tickets, agents, and settings are scoped to the company like the rest of the workspace, which keeps multi-tenant installs clean.
About this plugin
Why Ticketing Management for Orangescrum?
Support work is the quiet reason delivery plans slip. Requests arrive by email, chat, and conversation, they get handled by whoever is nearest, and none of it shows up in the plan. The sprint looks achievable right up to the point where half the team is answering tickets. This add-on gives incoming requests a queue, an owner, and a priority, in the same workspace the team delivers from.
A request and the work that answers it, in one place
The point of running tickets inside Orangescrum is that the request and the work do not sit in two different tools. Somebody asks for something, it becomes a ticket, the ticket is triaged and assigned, and the work happens in the system where the rest of your delivery already lives. Nobody re-types the same request into a second tracker.
Triage that is explicit rather than implied
Every ticket gets a priority and an owner. Ageing shows how long each one has been open. That turns an unranked pile of requests into a queue where the order is a decision somebody made, and where a slow ticket becomes visible before it turns into a complaint.
A workflow that matches how you actually resolve things
Tickets move through statuses you define. On the self-hosted edition you go further and design the allowed transitions and who is permitted to make them, so a ticket cannot jump from new to closed without passing through whatever step your process requires.
Evidence for the capacity conversation
Reporting covers ticket volume, ageing, and resolution time. Once support work is measured in the same place as project work, you can answer how much of the team's month went to unplanned requests with a number rather than an impression.
Where to read more
The Ticketing feature page at /ticketing-software covers how a ticket moves from capture to review, how tickets differ from tasks, and which capabilities are available in each edition. Related pages worth reading alongside it are /bug-and-issue-tracking for defect tracking and /custom-status-workflow for designing the status flow itself.
What's included
- Ticket intake into a single queue
- Priority and severity on every ticket
- Assignee and ownership per ticket
- Custom ticket statuses
- Control over allowed status transitions and who may make them
- Ticket ageing and response visibility
- Tickets sitting alongside project tasks in the same workspace
- Bug and defect tracking in the same workspace
- Reporting on ticket volume, ageing, and resolution time
- Access governed by your existing Orangescrum roles and permissions
- Multi-tenant company-scoped data isolation
Compatibility
Requires the Orangescrum Self-Hosted edition running PHP 8.2+, CakePHP 4.6+, and PostgreSQL 16. Ticketing is a licensed add-on module supplied with your add-on license, not a component of the base self-hosted download, so the ticketing build is provisioned for your specific Orangescrum version rather than copied from the standard package. It is available for the Cloud and Self-Hosted editions and is not part of the Community Edition. Confirm provisioning for your install with our team before you buy.
Installation
A self-hosted install takes a few minutes. Buy the add-on, drop the plugin into your plugins/ directory, run the migrations, and you're live.
- 1
Buy the add-on
Purchase the Ticketing Management add-on from /self-hosted/pricing at $499/year per company, payable annually.
- 2
Confirm provisioning for your install
Ticketing is supplied with your add-on license rather than bundled in the base self-hosted download. Our team confirms the right build for your Orangescrum version and sends you the plugin package.
- 3
Drop the plugin into your install
Copy the supplied plugin folder into plugins/ on your self-hosted Orangescrum server and register it in src/Application.php, following the same pattern as your other add-ons.
- 4
Run the database migrations
Run the migration command supplied with the package to create the ticket tables.
- 5
Decide who works the queue
Give ticket access to the people who will handle incoming requests, using your existing Orangescrum roles and permissions.
- 6
Define priorities and the status flow
Set the priority and severity values your team uses, then define the ticket statuses and which transitions are allowed for which roles.
- 7
Start taking requests
Point your incoming requests at the queue, triage the first batch, and check the volume and resolution reporting at the end of the period.
Frequently Asked Questions
How is a ticket different from a task?
▾
A ticket is an incoming request from somebody else, and it is usually unplanned. A task is planned work. Keeping both in one system is the entire point: it is the only way to see how much of your capacity unplanned work is really taking.
Does this replace a customer help desk?
▾
No, and it is worth being clear about that. This add-on handles request intake, triage, and resolution inside your delivery workflow. It is not a customer-facing help desk product: there is no public self-service customer portal, no customer satisfaction survey, and no knowledge base deflection. If a public customer portal is a hard requirement, evaluate against that requirement first.
Who works the tickets?
▾
The people you give ticket access to. Ticketing uses your existing Orangescrum roles and permissions rather than a second, separate access model, so you decide who can see and work the queue the same way you control the rest of the workspace.
Can tickets follow our own workflow?
▾
Yes. Tickets move through statuses you define. On the self-hosted edition you can also design which transitions are allowed and which roles may make them, so the flow enforces your process rather than describing it.
Can we report on ticket volume?
▾
Yes. Reporting covers volume, ageing, and resolution time over a period. That is the evidence to bring to a capacity conversation, because it turns an impression about support load into a measurement.
How is this different from bug and issue tracking?
▾
Bug tracking records defects in your product, usually found by your own team or by testing. Ticketing captures requests coming in from users or from the business. The two often connect, and both live in the same workspace, so a ticket that turns out to be a defect does not need re-entering.
Is ticketing in the Community Edition?
▾
No. The Community Edition covers projects, tasks, and Kanban boards. Ticketing is a licensed add-on module for the Cloud and Self-Hosted editions, supplied with your add-on license rather than bundled in the base download. Confirm provisioning for your Orangescrum version with our team before you buy.
Ready to deploy Ticketing Management on your own infrastructure?
Talk to our team about Orangescrum Self-Hosted Enterprise: your data, your servers, full control.