Configuring tickets
These tasks are done by an administrator. For what statuses, reasons, and SLA mean, see How tickets work.
Enabling the module
Section titled “Enabling the module”Tickets are an additional module, and until it is enabled its settings are not in the system.
- In the main menu on the left, open the Settings section.
- Select the Modules page.
- Find Tickets in the list and turn the toggle on.

After that, the tickets section appears in the menu, and the Ticket Settings page appears in the settings. For more about modules, see Modules.
How to open the ticket settings
Section titled “How to open the ticket settings”Most of the settings below are on a single page.
- Open the Settings section in the menu on the left.
- Select the Ticket Settings page.
- At the top of the page there are tabs: Categories, Routing, Statuses, Status reasons, Priorities, Types, and SLA. The instructions below refer to these tabs.

If there is no Ticket Settings page, the module is not enabled yet — go back to the Enabling the module step.
Categories, types, and priorities
Section titled “Categories, types, and priorities”On the Ticket Settings page, open the tab you need and fill in the directory by which requests will be classified:
- Categories — a hierarchical list of request topics. A category can be disabled without deleting it.
- Types — the nature of the request (for example, incident or request).
- Priorities — importance (for example, low, medium, high, critical).
On each tab, entries are added with the add button, edited with the pencil, and deleted with the trash icon. Custom fields can be linked to a category — then they appear in the ticket form for that category.
Status workflow
Section titled “Status workflow”Each ticket goes through statuses, for example: New → In Progress → Resolved → Closed. The workflow defines which status can be moved to from which. This keeps tickets moving in order and prevents skipping stages — for example, so that a ticket in the New status cannot be set to Closed right away, bypassing work on the ticket.
When an employee changes a ticket’s status, the system offers not all statuses in a row, but only those that the current one is allowed to transition to. This is the very list you define.
How to set the allowed transitions
Section titled “How to set the allowed transitions”- Open Settings (menu on the left) → Ticket Settings → the Statuses tab.
- In the list of statuses, click the pencil next to the status you need to open its settings.
- The status form has fields:
- Name — what the status is called (for example, “In Progress”).
- Code — the internal code; for system statuses it cannot be changed.
- Color — the color the status is displayed in on a ticket.
- Enabled — whether to show this status or not.
- Allowed next statuses — the main field: check here all the statuses the current one can transition to.
- Save.

Example. To keep a ticket from being closed without work being done, set the transitions like this:
- for the New status — allow a transition to In Progress (and, if needed, to Cancelled);
- for the In Progress status — to On Hold and Resolved;
- for the Resolved status — to Closed.
After that, you will not be able to go from New straight to Closed — only along the chain through In Progress and Resolved.
To create your own status, click the add button and fill in the same fields. System statuses (New, In Progress, On Hold, Resolved, Closed, Cancelled) can be edited only partially — for example, their code cannot be changed.
Reasons for changing status
Section titled “Reasons for changing status”Sometimes you need to record why a ticket was moved into a particular status — for example, why it was cancelled. Status reasons serve this purpose.
- On the Ticket Settings page, open the Status reasons tab.
- Click the add button and enter the Name of the reason (for example, “Duplicate” or “No reply from requester”).
- Specify which statuses this reason applies to (for example, the Cancelled status).
- Save.
Now, when a ticket is moved into such a status, the system asks you to select a reason and leave a comment — and both the reason and the comment are saved in the ticket history.
Configuring SLA
Section titled “Configuring SLA”SLA sets deadlines: time to first response and time to resolution. The deadlines are counted by the company’s business hours, so set those first (see Business hours below) — otherwise the deadlines will be counted incorrectly.
To add an SLA policy:
- Open the Settings section in the menu on the left.
- Select the Ticket Settings page.
- Go to the SLA tab.
- Click Add SLA Policy.
- Fill in the policy:
- Priority — which ticket priority this policy applies to.
- First Response — within how many minutes the first response must be given.
- Resolution — within how many minutes the ticket must be resolved.
- Business hours only — if on, time is counted only during business hours; if off — around the clock.
- Save.

Add one policy per priority that needs deadlines. After that, tickets with that priority show an SLA badge with a countdown.
Business hours
Section titled “Business hours”How SLA deadlines are counted depends on business hours.
- Open Settings in the menu on the left → the Working Hours page → the Business Hours tab.
- For each day of the week (Monday–Sunday), specify the working hours.
- If needed, add a break with the Add break button.
Time within these hours counts toward SLA, the rest does not (if Business hours only is on in the policy).
Holidays
Section titled “Holidays”Holidays and other non-working days are excluded from the SLA calculation.
- Open Settings → Working Hours → the Holidays tab.
- Click Add day and specify a Date and a Name.
- If the day recurs every year, turn on Repeats every year.
Routing rules
Section titled “Routing rules”Routing automatically assigns new tickets by type, category, and priority — for example, it sends critical hardware requests to the IT team. It is configured on the Routing tab of the Ticket Settings page.
- Open Settings (menu on the left) → Ticket Settings → the Routing tab.
- Click the add-rule button — the Assign Rule dialog opens.
- Enter the rule’s Name (required) — for example, “Critical hardware → IT team”.
- In the conditions block, define which tickets fall under the rule. Conditions are available for the Type, Priority, and Category fields. A ticket must match all of the conditions set; leave a field empty for it to match any value.
- In the assignment block, choose where to route matching tickets:
- Assign to Group — the queue team the ticket goes to. The specific assignee in it is chosen later.
- Assign to User — a specific assignee (optional).
- Leave the Rule enabled toggle on.
- Save.

Rules are checked top to bottom, and the first match wins. So place more specific rules above general ones.
If you assign a ticket to a group, then when choosing a specific assignee on the ticket itself the list is limited to members of that group — the notice Showing members of the selected group only points this out.