Working with Tickets
Creating, managing, and resolving support tickets.
Creating a ticket
Click New ticket from the dashboard or ticket list. Staff and admins can create tickets on behalf of any user. Users create tickets for themselves.
Required fields
- Subject — a short summary (max 255 characters). This is the ticket's title across all views.
- Description — the full detail of the request or issue. Markdown formatting is supported. Staff will read this first, so include all relevant context: error messages, steps to reproduce, what you've already tried.
- Category — required. At least one Category must be configured before any ticket can be created.
Optional fields
- Type — shown only if the selected Category has Types defined. Filters Items.
- Item — shown only if the selected Type has Items defined.
- Priority — defaults to Medium. Users can set priority if the admin has enabled User-selectable priority in settings. Staff and admins can always set and change priority.
- Attachments — files can be attached at creation. See Attachments.
CTI cascade behavior
The three dropdowns are chained:
- Selecting a Category fetches and populates the Type dropdown. If the Category has no Types, the Type field is not shown.
- Selecting a Type fetches and populates the Item dropdown. If the Type has no Items, the Item field is not shown.
- Changing the Category clears the Type and Item selections.
- Changing the Type clears the Item selection.
Guest ticket submission
When guest submission is enabled, the public submission form at /submit asks for an email address instead of requiring login. The subject, description, category, and email are required. Type, Item, and priority are shown if applicable. See Guest submission for how access links work.
Ticket lifecycle
A ticket moves through statuses over the course of its life. The default lifecycle is:
New → In Progress → Pending → Resolved → [reopen window] → Closed
↑ |
└── Reopened ──┘Statuses are customizable — admins can add intermediate statuses. The system statuses (New, Resolved, Closed) have fixed behavior regardless of their display name.
Status transitions
| Transition | Who can trigger it | Notes |
|---|---|---|
| Any status → any status | Staff, Admin | No restrictions except Closed (see below). |
| Any → Resolved | Staff, Admin | Optionally captures resolution notes. Starts the reopen window timer. |
| Resolved → Closed | System (automatic) | Triggered when the reopen window expires. A background job runs every hour to check. |
| Resolved → Reopened (via reply) | User | Only within the reopen window. Automatically transitions the ticket back to New. |
| Closed → any | Staff, Admin only | Users cannot interact with Closed tickets. |
| Resolved or Closed → Reopened (manual) | Staff, Admin | Bypasses the reopen window restriction. |
Resolution notes
When marking a ticket Resolved, staff are prompted to optionally enter resolution notes — a brief summary of what was done and how the issue was fixed. These notes are visible to the submitter and are preserved when the ticket is reopened. They're useful for building a history of known fixes.
The reopen window
After a ticket is Resolved, the submitter has a configurable number of days to reopen it by replying. The default is 7 days. When a user adds a reply to a Resolved ticket within the window:
- The reply is saved.
- The ticket status is automatically changed back to New.
- The ticket is flagged in the staff queue as reopened.
- The original assignee (if any) receives an email notification.
After the window expires, the ticket transitions to Closed automatically. Users can still view Closed tickets but cannot add replies. Staff can reopen Closed tickets manually at any time.
Replies & internal notes
Public replies
Public replies are the standard response mechanism. They are visible to:
- The ticket submitter
- All staff and admins who have access to the ticket
- Guest users with a valid access link (for guest-submitted tickets)
Email notifications are sent to all participants when a public reply is added.
Internal notes
Staff and admins can add internal notes to any ticket. Internal notes are:
- Never visible to users or guests, regardless of their access level.
- Not included in email notifications to users or guests.
- Visually distinguished in the ticket thread with a different background color and a "Internal note" label.
- Visible to all staff and admins who can see the ticket.
Use internal notes for:
- Recording investigation steps and findings
- Noting escalation decisions and reasons
- Coordinating with other staff members ("I'll contact the vendor, you handle the user")
- Linking to internal tools or runbooks
- Documenting failed solutions before finding the correct one
Markdown support
Both replies and notes support a subset of Markdown:
**bold**and*italic*- Inline code with backticks:
`code` - Code blocks with triple backticks (with optional language hint for syntax highlighting)
- Ordered and unordered lists
- Links:
[text](url) - Blockquotes with
>
HTML is not supported and is escaped before rendering.
Editing and deleting replies
Users can edit or delete their own replies within 15 minutes of posting. Staff and admins can edit any reply at any time. Deletions are soft — a "deleted reply" placeholder is shown to staff. The original content is preserved in the audit log.
Linked tickets
Any ticket can be linked to any other ticket, regardless of status. Links are always bidirectional — adding a link on ticket A automatically creates the reverse link on ticket B.
Link types
| Type | Meaning | When to use |
|---|---|---|
related_to |
These tickets are related in some way. | They affect similar systems, came from the same user, or are otherwise connected but neither caused the other. |
parent_of / child_of |
One ticket is a sub-issue of another. | A "batch laptop deployment" parent ticket with individual "setup laptop for [user]" children. Or a widespread network outage parent with individual "I can't access the VPN" children. |
caused_by |
This ticket was caused by another ticket's issue. | A failed Windows update ticket caused several "Outlook won't open" tickets. |
duplicate_of |
This ticket is a duplicate of another. | A user submitted the same request twice. Mark the newer one as a duplicate of the original. |
Adding a link
From the ticket detail view, click Add link in the Linked tickets section. Search for the target ticket by ID or by subject keywords. Select the link type and confirm.
Removing a link
Click the × next to any linked ticket. This removes the link in both directions. Staff and admin only — users cannot modify links.
Bulk operations on linked tickets
From a parent ticket, staff can resolve all child tickets at once using Resolve all children. Each child receives the same resolution notes as the parent. This is useful for closing out many individual duplicate or child tickets after resolving the root cause.
Assignment
A ticket can be assigned to:
- A specific staff member — the ticket appears in their personal queue and they receive an email notification.
- A group — the ticket appears in the queue of every member of that group. Useful when you want a team to handle the ticket without specifying an individual.
- Unassigned — visible to all staff with scope for the ticket's CTI classification.
Who can assign
Staff and admins can assign tickets to any staff member or group, regardless of scope. This is intentional — cross-team escalation should not be blocked by routing rules. A ticket can be assigned to staff outside their normal scope, and it will appear in the assignee's queue.
Self-assignment
Staff can click Assign to me to take ownership of an unassigned ticket immediately.
Reassignment
Reassigning a ticket (changing from one assignee to another) generates an email notification to the new assignee. The old assignee does not receive a notification unless they are also a participant (i.e. they added a reply).
Assignment and scope
Scope controls what tickets a staff member sees in their default queue. Assignment overrides this for the assignee — if you are assigned a ticket outside your scope, it appears in your queue. You can always find any ticket by its ID using the search bar, regardless of scope or assignment.
Attachments
Files can be attached to a ticket at creation or in any reply. All attachments are served through the API and require authentication to download.
Limits
| Limit | Default | Configurable? |
|---|---|---|
| Maximum file size | 25 MB per file | Yes — Admin → Settings → Max attachment size |
| Files per upload | 10 files | No |
| Total per ticket | Unlimited | No |
Allowed file types
The following types are blocked regardless of extension: .exe, .bat, .cmd, .sh, .ps1, .vbs, .dll, .so, .dylib. All other MIME types are accepted including images, PDFs, Office documents, archives, and text files.
Files are stored with randomized names in ATTACHMENT_DIR to prevent enumeration. The original filename is preserved in the database and displayed in the UI.
Guest access to attachments
Guests with a valid access link can download attachments on their ticket. The download URL includes the same authentication token as the access link — no separate login is required.
Search & filtering
Quick search
The search bar at the top of the ticket list searches subject lines. Staff and admins can also enter a ticket ID directly to navigate to it immediately.
Filters
The ticket list can be filtered by:
- Status — one or multiple statuses. Default view shows all non-Closed tickets.
- Priority — Critical, High, Medium, Low.
- Assignee — my tickets, unassigned, or a specific staff member.
- Group — tickets assigned to a specific group.
- Category / Type / Item — narrow to a specific CTI path.
- SLA status (if SLA is enabled) — within SLA, at risk, breached.
- Date range — created between two dates.
Sorting
Sort the ticket list by: newest, oldest, last updated, priority (high to low), or SLA deadline (soonest first). The default sort is last updated descending.
Saved views (staff and admin)
Staff can save any combination of filters and sort order as a named view. Saved views appear in the left sidebar under My Views. Admins can publish shared views visible to all staff.