Tickets in management view
This page explains how staff use the ticket queue in the admin area.
Navigation path:
Server Admin->Tickets
For the shared lifecycle and Discord behavior behind the queue, see Tickets concept.
Access requirementsโ
tickets.admin_viewfor read-only access to the queue and ticket detailtickets.replyto create staff tickets, send public replies, pin messages, and upload evidence filestickets.internal_messageto add internal notestickets.assignto assign tickets, manage participants, and edit the subjecttickets.change_statusto change the ticket status manuallytickets.add_participantto add participants directly from the Discord ticket channel using the user-selectlogs.viewto access the Investigation tab and re-run saved log queries from the Review tabrestrictions.viewto view linked restrictions on the Review tabrestrictions.createto create new restrictions directly from a ticket
Compatibility note:
Existing support groups that already have tickets.reply, tickets.internal_message, tickets.assign, or tickets.change_status can still open the queue even without tickets.admin_view. For new role setups, grant tickets.admin_view explicitly if the role needs read-only access.
Attention badgesโ
Every ticket row in the queue displays a badge indicating who should respond next:
- Needs Attention (red) โ the last public message is from a player; support has not yet replied
- Waiting for Response (grey) โ the last public message is from support; the player has not yet replied
Use the Needs Attention badge to quickly spot tickets that are waiting for a staff response.
Queue overviewโ
The queue supports these filters:
- status tabs
- unassigned tickets
- tickets assigned to the current staff member
- participant search
- assignee search
Use these filters to split first-response work, assigned follow-up work, and player-specific investigations.
Participant and assignee search each use the player lookup. Start typing at least two characters to narrow the queue to a specific player.
Creating a staff ticketโ
If tickets.reply is granted, staff can create a ticket directly from the queue.
This is useful for:
- internal support follow-up
- staff-initiated outreach
- moving Discord-side support into a tracked ticket flow
Staff-created tickets start without a player participant until one is added.
Ticket detailโ
The detail page is organized into three tabs: Conversation, Investigation, and Review.
The Conversation and Review tabs are always visible. The Investigation tab is only shown for active tickets (Open or In Progress) and requires logs.view.
Conversation tabโ
The Conversation tab contains the full message thread and the core ticket operations:
- public replies for player-visible communication
- internal notes for staff-only context
- assignment and unassignment
- participant management
- subject editing
- status changes
- manual response-waiting state
Important behavior:
- the first public support reply auto-assigns an unassigned ticket to that staff member
- adding a faction includes all current faction members as participants
- internal notes stay private in dzbot and do not expose their content to players
- each message can be pinned using the pin icon; pinned messages appear on the Review tab for quick reference during case review
Response-waiting state
Staff can manually set the response-waiting state on active tickets without sending a message:
- Waiting for Support โ marks the ticket as needing a staff response
- Waiting for Player โ marks the ticket as waiting on the player
This controls the same field that updates automatically when a public message is sent. Use the manual toggle when working on a ticket internally without yet sending a public reply, so the queue badges stay accurate.
Requires tickets.reply.
Investigation tabโ
Requires logs.view. Only visible on active tickets (Open or In Progress).
Embeds the log explorer directly in the ticket, so staff can research in-game events without leaving the page:
- filter logs by event type, player, coordinates, and time range
- save the current filter configuration as a named query attached to the ticket
- pin individual log events with an optional annotation note
Saved queries and pinned events are stored against the ticket and remain accessible on the Review tab to staff who do not have logs.view. Only running new queries or pinning new events requires the right.
Review tabโ
Always visible. Collects all evidence and outcomes accumulated for a ticket.
Linked restrictions โ requires restrictions.view. Shows all restrictions linked to this ticket. Staff with restrictions.create can open the New restriction menu to create an event or system restriction directly from the ticket. New restrictions open in a side drawer and are automatically linked.
Evidence files โ files attached to the ticket (images, PDF, video). Staff with tickets.reply can upload additional files using Upload evidence file. Attachments added inline during a reply also appear here.
Saved queries โ filter configurations saved from the Investigation tab. Each can be re-run (requires logs.view) to fetch fresh results in a modal. Queries can be deleted when no longer needed.
Pinned events โ log events pinned during investigation, displayed with any annotation added at pin time. Events can be unpinned directly from this tab.
Pinned messages โ conversation messages marked with the pin icon on the Conversation tab. Messages can be unpinned from here.