Ticket Management

Ticket management turns alerts, search findings, or other to-dos into assignable, trackable work items. Built for SOC shifts and cross-team collaboration: one person discovers, many follow through, with an auditable trail. Tickets often live under the alert app or a dedicated Tickets menu, linked both ways with Alerts.

Version note (2.4): Current product documentation. Behavior follows the 2.4 environment.

What you can do

• Create tickets in one step from alerts or Data Search results
• Create tickets manually and assign to users, departments, or groups
• Update status and add comments that form a handling timeline
• Filter by status, assignee, and priority; close or archive when done
• Trace source alerts, operators, and timestamps in ticket details
• Hand off open items between shifts using status, comments, and priority

Before you start

• Account has ticket permissions (view, create, handle, archive)
• Common path: Security Operations �?Ticket Management or Tickets (UI may vary)
• Assignee accounts exist and can log in to receive work
• For alert-origin tickets: selectable events exist in Alerts
• Status changes and comments are stored in the handling timeline for audit and handover
• If assignees need email/in-app notice, confirm channels in System Administration

Common tasks

1. Create a ticket from an alert

1. Open Alert Management �?Event Alerts; select alerts to escalate
2. Choose Create Ticket (or equivalent in alert details)
3. Enter title, description, priority; assign to user / department / group
4. Confirm; the new ticket appears in Ticket Management with source alert ID or link
5. For multi-team work on one incident, create linked tickets and cross-reference in descriptions
6. Notify assignees after creation if the platform supports it—avoid unowned tickets

You can also create tickets from selected events in Data Search; paste time window and key fields into the description.

2. Create and assign manually

1. Open Ticket Management (Tickets menu)
2. Click New Ticket
3. Enter title, description, priority, and initial status (e.g. new / pending)
4. Choose assignment category and assignee; save
5. Assignees open the ticket from their queue or list
6. For cross-department work, state expected completion and acceptance criteria in the description
7. For high priority, also notify the on-call lead if your process requires it

3. Handle, comment, and audit

1. Filter the list by status, assignee, or priority; locate the ticket
2. Select Handle Ticket or open details
3. Update assignee (reassign), outcome, and handling notes (comments)
4. Each note appears on the handling timeline with operator and timestamp
5. Log major actions separately (isolate host, reset password, patch applied) for audit
6. Do not paste unredacted passwords or full PII in comments
7. On reassignment, state reason and next owner to avoid gaps

4. Close and archive

1. Set status to Closed or equivalent terminal state when work is done
2. Before close: confirm root cause handled or moved to a long-term tracker
3. Use Archive with reason when you need retention without active follow-up
4. If sourced from Alerts, set alert disposition to resolved for consistency
5. Periodically review time-to-close, overdue tickets, and repeat-open causes

5. Shift handover

1. Before handoff, filter open + high-priority tickets
2. For each, summarize progress, blockers, next action, and contact
3. Incoming shift adds a brief “accepted handover�?comment per team convention
4. Align assignees with on-call rosters in System Administration
5. Verbal to-dos from hunts or search should become tickets to avoid drops

Parameters (ticket fields)

Do not put real passwords, customer public IPs, or unredacted connection strings in docs, screenshots, or tickets.

FAQ (this module)

1. Symptom: Ticket created from alert but assignee sees no work item �?Cause: Wrong assignee, missing ticket permission, or notification not delivered. �?Fix: Verify group membership and permissions; reassign and notify manually.

2. Symptom: Ticket closed but alert still open �?Cause: States not synced or wrong ticket linked. �?Fix: Confirm alert linkage in details; update alert disposition after close.

3. Symptom: Handling timeline lacks comments for audit �?Cause: Team only changes status without notes. �?Fix: Require a short note on each status change; spot-check in reviews.

4. Symptom: Duplicate tickets for the same incident �?Cause: Shifts did not search existing tickets before create. �?Fix: Search by source alert ID or entity before create; merge or link duplicates.

How to confirm success

• Alert or finding maps to one searchable ticket
• Assignee is correct; status flows new �?in progress �?closed/archived
• Timeline shows notes and timestamps with clear ownership
• Next shift can continue from status and comments
• Source Alert disposition matches closed ticket
• High-priority tickets show progress within expected SLA

Related docs

• Alerts
• Data Search
• Threat Hunting
• System Administration

:::caution This documentation is for online viewing only. Source files and bulk download are not provided. :::