Cases Management

A Case groups related alert events into one investigation unit with a status, priority, category, and assignee. Use manage_cases to inspect a case and drive its lifecycle: ACTIVE → ACKNOWLEDGED → RESOLVED → CLOSED.

Tool actions

Action	Required inputs	Purpose
events	case_ids	Inspect the first case's timeline.
get_event	event_id	Inspect one event in detail.
notifications	case_ids	Inspect delivery records for one or more cases.
update	case_ids, title and/or resolution_reason	Update mutable fields on the first case.
comment	case_ids, text	Add an investigation note to the first case timeline.
assign / unassign	case_ids, user_id for assign	Set or remove the first case assignee. user_id must be a Coralogix user ID.
acknowledge / unacknowledge	case_ids	Claim work on the first case or return it to active.
set_priority / clear_priority	case_ids, priority for set	Override priority with P1–P5 or restore the computed priority.
resolve	case_ids, reason	Resolve the first case with a meaningful reason. Irreversible.
close	case_ids	Close the first case. Terminal.

case_ids is always a list. Lifecycle actions and events use only its first entry; notifications uses every entry.

Lifecycle

PENDING_ACTIVATION → ACTIVE ↔ ACKNOWLEDGED
                         ↘       ↙
                           RESOLVED → CLOSED
ACTIVE ───────────────────────────→ CLOSED

• unacknowledge is the only reverse transition: ACKNOWLEDGED → ACTIVE.
• RESOLVED cannot be reopened; it can only be closed.
• CLOSED is terminal.
• Priorities run from P1 (highest) to P5. An override is distinct from the system-calculated priority.

Triage workflow

1. Inspect the live case with get_alerts_object; use its UUID or readable ID such as CASE-123.
2. Inspect the timeline with manage_cases(action="events") and notification delivery outcomes with manage_cases(action="notifications").
3. Investigate the underlying Alert Definition and triggering telemetry before changing lifecycle state. Load the coralogix-alerts and coralogix-single-case skills.
4. Assign and acknowledge only after the user confirms ownership.
5. Record findings, links, root cause, and mitigation in a comment.
6. Resolve only with a meaningful reason; if impact differs from the calculated priority, set or clear an override while the case remains open.
7. Re-fetch the case after a mutation when confirmation of current state is required.

Safety rules

• Never infer acknowledgement, resolution, or closure from an investigation result; obtain explicit user confirmation.
• resolve is irreversible and close is terminal. Prefer leaving an uncertain case acknowledged.
• Add a comment before resolving or closing when the case lacks investigation or remediation context.
• Do not fabricate case IDs or Coralogix user IDs.

Examples

{"action":"comment","case_ids":["CASE-123"],"text":"Mitigation deployed; monitoring recovery."}

{"action":"set_priority","case_ids":["CASE-123"],"priority":"P1"}

{"action":"notifications","case_ids":["CASE-123","CASE-456"]}

References

• Single-case investigation
• Case analytics