JoomHelpdesk - Ticket Statuses & Priorities Guide

Parent Category: Documentation JoomHelpdesk Documentation Last Updated: 03 February 2026 Hits: 286

Statuses and priorities are two foundational elements of every helpdesk ticket in JoomHelpDesk. Statuses define where a ticket sits in the support workflow (new, awaiting a reply, closed, etc.), while priorities indicate the urgency level (low, medium, high, etc.). Together they give both customers and support agents a clear picture of every ticket at a glance.

This guide covers how to create, configure, and use statuses and priorities, how the built-in workflow automation works, and which settings control each behavior.

Ticket Statuses
Status Workflow
Ticket Priorities
Settings Reference
Tips

1. Ticket Statuses

What Statuses Represent

A ticket status tells everyone involved -- the customer, the support agent, and the system -- what stage of the support process a ticket is in. Every ticket always has exactly one status. When an action occurs (a reply is posted, the ticket is closed, etc.), the status can change automatically according to the rules you configure.

Default Statuses

JoomHelpDesk ships with a set of built-in statuses that cover a standard support workflow:

Status	Typical Purpose	Is Closed?
New	Ticket just created, not yet reviewed	No
Open	Being actively handled by an agent	No
Pending / User Reply	Agent replied, awaiting customer response	No
Closed	Issue resolved, no further action needed	Yes
Archived	Long-term storage of old tickets	Yes

You can rename, reorder, add, or remove statuses to match your own workflow. The only requirement is that certain default flags remain assigned (see Default Status Flags below).

Managing Statuses

To manage statuses, go to:

Administrator > Components > JoomHelpDesk > Statuses

This opens the status list view where you can create, edit, reorder, publish/unpublish, and delete statuses.

Status Edit Form Fields

When you create or edit a status, the following fields are available:

Field	Description
Title	The internal name of the status, visible to agents in the backend and frontend admin panel. This value is also translatable for multi-language sites.
Display to User As	An optional alternative label shown to customers. If left blank, the Title is used. Useful when you want agents to see a technical name (e.g., "Pending - L2 Escalation") but customers to see something simpler (e.g., "In Progress"). This value is also translatable.
Color	A CSS color value (e.g., `#ff0000` or `red`) used to color-code the status in ticket lists and detail views.
Combine for Users With	Lets you merge this status visually for customers with another status. When set, customers see tickets with this status as if they belong to the selected target status. This is useful for creating internal-only statuses (e.g., "Escalated") that customers simply see as "Open". Set to "Don't Combine" to show this status independently.
Ordering	Controls the display order in dropdown menus and lists. Managed via the hidden ordering field and the list view's ordering controls.
Translation	Stored as a hidden field. You can translate the Title and Display to User As values into other installed languages using the Translate toolbar button.

Status List View

The status list view (Administrator > Components > JoomHelpDesk > Statuses) shows all statuses in a table with the following columns:

Column	Description
#	The database ID of the status.
Checkbox	Select statuses for bulk actions.
Title	The status name. If a "Display to User As" value is set, it appears below the title in grey. Click the title to edit.
Color	Displays the configured color value.
Defaults group (5 columns)	Toggle buttons for the five default flags: New Ticket, After User Reply, After Admin Reply, Closed, and Archive. Only one status can hold each flag at a time (clicking a flag on one status clears it from all others). Some combinations are mutually exclusive and show "N/A" when not applicable.
Is Closed	Whether the status counts as a "closed" state. Automatically set to Yes for the Closed and Archive default statuses. Can be manually toggled for custom statuses.
Can Auto-Close	Whether tickets in this status are eligible for the auto-close cron job. Only available for non-closed statuses.
Own Tab	Whether this status gets its own dedicated tab/filter in ticket list views.
Published	Publish or unpublish the status. Default statuses (New Ticket, After User Reply, After Admin Reply) cannot be unpublished.
Order	Reorder statuses using the up/down arrows or by typing a number directly.

The "Is Closed" Concept

The Is Closed flag is central to how JoomHelpDesk distinguishes between active and resolved tickets:

Closed statuses remove the ticket from the active queue. Customers see these tickets as resolved.
Closed statuses hide the reply form from customers by default (unless the reopen setting is enabled).
The Closed and Archive default statuses are always forced to Is Closed = Yes and cannot be toggled off.
You can create additional custom closed statuses (e.g., "Resolved - No Fix", "Duplicate") by toggling Is Closed to Yes.
Tickets in a closed status are excluded from auto-close processing (since they are already closed).
The Is Closed flag is also used to determine whether a customer can reopen a ticket (controlled by the support_user_can_reopen setting).

Combining Statuses for Users

The "Combine for Users With" feature creates internal-only statuses that are invisible to customers. For example:

Create a status called "Escalated to L2" for internal tracking.
Set its "Combine for Users With" to "Open".
Agents see the ticket as "Escalated to L2", but customers see it as "Open".

This is valuable when your internal workflow has more stages than you want to expose to customers.

2. Status Workflow

Default Status Flags

JoomHelpDesk uses five special default flags to automate status transitions. Each flag can be assigned to exactly one status at a time. You assign them by clicking the toggle icons in the Defaults columns of the status list view.

Flag	Purpose
New Ticket (`def_open`)	The status automatically assigned when a new ticket is created.
After User Reply (`def_user`)	The status automatically assigned when a customer posts a reply. Can be unset if you do not want automatic status changes on user reply.
After Admin Reply (`def_admin`)	The status automatically assigned when a support agent posts a reply. Can be unset if you prefer agents to set the status manually.
Closed (`def_closed`)	The status used when a ticket is closed (by agent, customer, or auto-close). Automatically marked as Is Closed. Cannot overlap with New Ticket, After User Reply, After Admin Reply, or Archive.
Archive (`def_archive`)	The status used for archived tickets. Automatically marked as Is Closed. Cannot overlap with New Ticket, After User Reply, After Admin Reply, or Closed.

Status on Ticket Create

When a customer (or guest) submits a new ticket, the system automatically assigns the status marked with the New Ticket default flag. No manual intervention is required.

Status After User Reply

When a customer posts a reply to an existing ticket:

If a status is marked with the After User Reply flag, the ticket status is automatically changed to that status.
If this flag is unset (no status assigned), the ticket status remains unchanged after a user reply.
If the ticket was in a closed status and the customer is allowed to reopen it (support_user_can_reopen is enabled), the reply reopens the ticket and changes its status to the After User Reply status.

Status After Agent Reply

When a support agent posts a reply:

If a status is marked with the After Admin Reply flag, the ticket status is automatically changed to that status.
If this flag is unset, the ticket status remains unchanged. The agent can still manually change the status using the status dropdown in the reply form.

Status on Close

When a ticket is closed (whether by an agent, by the customer using the close button, or by the auto-close cron job), the ticket is moved to the status marked with the Closed default flag.

Status on Archive

Archive serves as a secondary closed state for long-term storage. Tickets can be moved to the Archive status by agents. Archived tickets are treated as closed (Is Closed is always Yes for the archive status).

User Permissions for Status Changes

Three settings in Settings > User control what customers can do with ticket statuses:

Setting	Key	Description	Default
User Can Close Tickets	`support_user_can_close`	When enabled, customers see a "Close Ticket" button on their open tickets.	Enabled
User Can Reopen Tickets	`support_user_can_reopen`	When enabled, customers can reply to closed tickets, which reopens them to the After User Reply status. If disabled, the reply form is hidden on closed tickets.	Enabled
User Can Change Status	`support_user_can_change_status`	When enabled, customers see a status dropdown on the ticket and can manually change the status themselves.	Disabled

There is also a related setting:

Setting	Key	Description
Show Close on Reply	`support_user_show_close_reply`	When enabled together with `support_user_can_close`, a "Close and Reply" checkbox is shown in the reply form, allowing the customer to close the ticket and post a final reply in one step.

Auto-Close

Auto-close automatically closes tickets that have been idle for a configurable number of days. It is managed via a built-in cron job.

How it works:

Enable auto-close in Settings > General > Auto-Close Settings by checking the "Automatically Close" checkbox.
Set the Auto-Close Duration -- the number of days of inactivity after which tickets will be closed.
Optionally enable Add to Audit Log to record the auto-close action in the ticket's audit trail.
Optionally enable Email User to notify the customer when their ticket is auto-closed.

Which tickets are auto-closed:

Only tickets whose current status has the Can Auto-Close flag set to Yes in the status list are eligible.
Tickets in a closed status (Is Closed = Yes) are never auto-closed (they are already closed).
The Can Auto-Close flag is togglable per status, so you can control exactly which open/pending statuses participate in auto-close.

Cron requirement: Auto-close runs via the JoomHelpDesk cron system. You must have a server-side cron job or Joomla's Task Scheduler calling the cron URL regularly for auto-close to function. The cron URL is displayed in the auto-close settings area.

3. Ticket Priorities

What Priorities Represent

Priorities indicate how urgent a ticket is. They help support agents decide which tickets to handle first and can be used to sort and filter the ticket list. Unlike statuses, priorities do not drive workflow automation -- they are purely informational labels with visual styling.

Default Priorities

A typical JoomHelpDesk installation includes priorities such as:

Priority	Typical Color
Low	Green or grey
Medium	Blue or default
High	Orange
Urgent / Critical	Red

You can rename, add, remove, or reorder priorities to suit your needs.

Managing Priorities

To manage priorities, go to:

Administrator > Components > JoomHelpDesk > Priorities

This opens the priority list view where you can create, edit, reorder, and search priorities.

Priority Edit Form Fields

When you create or edit a priority, the following fields are available:

Field	Description
Priority (Title)	The name of the priority level (e.g., "High", "Low"). This value is translatable for multi-language sites.
Color	A CSS color value (e.g., `#ff0000`) used as the text color when displaying this priority. A live preview swatch labeled "Example" updates as you type.
Background Color	A CSS color value used as the background highlight when displaying this priority in lists. A live preview swatch updates as you type. Using both color and background color together creates strong visual differentiation (e.g., white text on a red background for "Urgent").
Ordering	Controls display order in dropdown menus and lists. Stored as a hidden field, managed through the list view.
Translation	Translates the priority title into other installed languages via the Translate toolbar button.
Access	Controls which Joomla access levels can see this priority (stored in the database table).

Priority List View

The priority list view (Administrator > Components > JoomHelpDesk > Priorities) shows all priorities in a table with the following columns:

Column	Description
#	The database ID of the priority.
Checkbox	Select priorities for bulk actions.
Priority	The priority name. Click to edit.
Color	Displays the color value in the configured text color, providing a visual preview.
Back Color	Displays the background color value with the configured background color applied to the cell.
Order	Reorder priorities using the up/down arrows or by typing a number directly.

The list also includes a search/filter bar to find priorities by name.

Default Priority Setting

You can set which priority is pre-selected when a customer opens a new ticket:

Go to Settings > Ticket Opening.
Find the Default Priority dropdown.
Select a priority from the list, or choose the default option (which typically uses the first priority in the ordering).

When a customer opens a new ticket and does not change the priority (or when priority is hidden from users), the system assigns this default priority.

Hiding Priority from Users

The Hide Priority setting in Settings > General > Features controls whether customers can see and set the priority:

Value	Behavior
Shown (0)	Priority is visible to everyone. Customers can select a priority when opening a ticket and see it on ticket views and lists.
Hidden (1)	Priority is completely hidden from all users, including agents. It does not appear in ticket forms, ticket views, or list columns. The default priority is still assigned internally.
Admin Only (2)	Priority is hidden from customers but visible to support agents in their admin panel. Agents can set and change priority; customers cannot see it.

4. Settings Reference

All settings related to statuses and priorities, with their locations:

Setting	Key	Location	Values	Description
User Can Close Tickets	`support_user_can_close`	Settings > User	Checkbox (on/off)	Allow customers to close their own tickets.
User Can Reopen Tickets	`support_user_can_reopen`	Settings > User	Checkbox (on/off)	Allow customers to reopen closed tickets by replying.
User Can Change Status	`support_user_can_change_status`	Settings > User	Checkbox (on/off)	Allow customers to manually change ticket status via a dropdown.
Show Close on Reply	`support_user_show_close_reply`	Settings > User	Checkbox (on/off)	Show a "Close and Reply" option in the customer reply form. Requires `support_user_can_close` to also be enabled.
Hide Priority	`support_hide_priority`	Settings > General > Features	0 = Shown, 1 = Hidden, 2 = Admin Only	Controls priority visibility for users.
Default Priority	`support_default_priority`	Settings > Ticket Opening	Priority ID or blank	The priority pre-selected on the ticket creation form.
Automatically Close	`support_autoclose`	Settings > General > Auto-Close	Checkbox (on/off)	Enable/disable the auto-close cron job.
Auto-Close Duration	`support_autoclose_duration`	Settings > General > Auto-Close	Number (days)	Days of inactivity before a ticket is auto-closed.
Add to Audit Log	`support_autoclose_audit`	Settings > General > Auto-Close	Checkbox (on/off)	Log auto-close events in the ticket audit trail.
Email User on Auto-Close	`support_autoclose_email`	Settings > General > Auto-Close	Checkbox (on/off)	Send an email notification to the customer when their ticket is auto-closed.

5. Tips

Start with the defaults. The built-in statuses (New, Open, Pending, Closed) cover most workflows. Only add custom statuses when you have a genuine need for them.
Use "Combine for Users With" for internal statuses. If your team needs statuses like "Escalated", "Waiting on Third Party", or "In Development", create them and combine them with a customer-friendly status like "Open" so customers are not confused.
Use "Display to User As" for clarity. Agents may understand "Pending - L2" but customers respond better to "We're Working On It". Set the user-facing label without changing the internal name.
Set Can Auto-Close thoughtfully. Enable auto-close only on statuses where inactivity means the issue is likely resolved (e.g., "Pending / User Reply"). Do not enable it on "New" or "Open" where the agent may simply be busy.
Use color and background color together on priorities. A red background with white text for "Urgent" creates instant visual impact in ticket lists, helping agents spot critical tickets at a glance.
Hide priority if it causes confusion. If customers always select "Urgent" regardless of actual urgency, set priority to "Admin Only" so agents can set it themselves based on the actual issue.
Set a sensible default priority. Choosing "Medium" as the default prevents every ticket from being flagged as the highest urgency while still allowing customers (or agents) to escalate when needed.
Do not delete default statuses. The system prevents deletion of statuses that are assigned as New Ticket, After User Reply, or After Admin Reply defaults. If you want to replace a default status, first assign the default flag to a different status, then delete the old one.
Do not unpublish default statuses. Similar to deletion, the system blocks unpublishing statuses that serve as defaults for New Ticket, After User Reply, or After Admin Reply. Reassign the flag first.
Test your workflow. After changing statuses or their default flags, open a test ticket, reply as a customer, reply as an agent, and close the ticket. Verify that the status transitions match your expectations at each step.

Documentation

Find documentation for our Joomla extensions on this page.