Run an investigation with Case Files

Prerequisites

Product permissions cases.read and cases.write for case changes.
Valid same-tenant finding, change, evidence, architecture, workload, or investigation references.
A named owner and measurable verification criteria.

Route

/cases and /cases/:id.

How to open and scope a case

Open /cases and create a case with a concise, non-sensitive title, summary, and severity.
Assign an owner and link workload, architecture, and investigation chat when available.
Open /cases/:id and confirm status open, risk/confidence, assignee, and scope.
Add an initial note stating impact, known facts, unknowns, and next step.
Move to investigating.

Expected result: A durable case with an append-only opening timeline.

Verification: Refresh the page and confirm case metadata and opened, assignment, note, and status events persist.

How to build an investigation timeline

Attach validated finding UIDs, change-event IDs, and Evidence Locker snapshot IDs.
Link the investigation chat rather than copying sensitive transcripts.
Add timestamped notes for hypotheses, tests, decisions, and rejected explanations.
Correct mistakes with a new note; timeline events and notes are not edited in place.
Update severity, risk, confidence, summary, or assignee when evidence changes.

Expected result: A chronological record connecting evidence, decisions, ownership, and handoffs.

Verification: Open every reference and confirm same-tenant scope, relevance, and integrity.

How to remediate and verify a case

Record the approved remediation and rollback reference.
Move to remediating only when execution ownership is clear.
Apply the change through the approved external system.
Capture fresh telemetry, inventory, quota, policy, identity, RBAC, or evidence as appropriate.
Move to verifying and record measurable expected versus observed results.
Resolve when success criteria are met; close after operational follow-up.

Expected result: A case whose resolution is supported by fresh verification evidence.

Verification: Confirm source symptoms are absent or controlled, no unacceptable regression exists, and attachments/timestamps postdate remediation.

How to reopen or delete a case safely

Reopen or move status backward when new evidence invalidates resolution; status transitions are allowed in either direction and remain logged.
For an erroneous case, review references and external tickets before deletion.
Use the delete action only after retention approval and the warning that the case and timeline are permanently deleted.
Preserve required evidence elsewhere first; deleting a case does not delete external tickets or source records.

Expected result: Reopened work remains auditable; permanent deletion removes the case record only.

Verification: Reopened status and reason appear in the timeline. A deleted case is absent and cannot be restored through the UI.

Safety and rollback

Case writes affect local records, not Azure resources. Notes are append-only and should contain no secrets, access tokens, share tokens, raw customer payloads, or unnecessary personal data. Status and metadata can be changed again; timeline history remains. Permanent case deletion has no rollback. External remediation uses its own approved rollback.

Freshness and partial results

Case metadata and timeline are database-backed and current when loaded, but attached evidence is point-in-time and linked source objects can age, be removed, or remain partial. A case summary is not automatically synchronized with external tickets or Azure state.

Troubleshooting

Symptom	Resolution
Case is absent	Check ID and filters; confirm it was not permanently deleted.
Attachment fails	Confirm object type, same tenant, existence, and write permission.
Assignee is unavailable	Refresh access-control data and verify the user/role.
Resolution lacks confidence	Return to investigating/verifying and collect fresh evidence.
Timeline appears out of order	Compare absolute creation timestamps and client time zone.