Security Incidents

Coordinate active security incidents with severity, owner, affected systems, timeline, evidence, and containment status visible. The screen connects Incidents and Alerts so workspace admins can find the “Create incident” action while checking open and critical.

Use this reference when you need to design this workflow inside an existing product. The example includes practical records such as Suspicious admin login and Credential leak detected, rather than an empty visual shell.

Security Incidents

Template facts

Screen

Inbox

Primary action

Create incident

Pattern

Inbox

State

Default, loading, empty, error, permission, success

Design system

Adaptable product UI theme

What this screen helps users do

Workspace admins need a clear “Create incident” action without losing sight of open, critical and the affected records. Keep the decision and its outcome clear before moving to the next task.

Key elements

  • Primary action: Create incident is clearly available where the task happens.
  • Main view: Incidents keeps the starting point obvious.
  • Connected view: Alerts supplies nearby context.
  • Metric: Open is visible with a meaningful value.
  • Another signal: Critical helps people judge what to do next.
  • Representative record: Suspicious admin login makes the example specific.
  • Second record: Credential leak detected shows the pattern works beyond one item.

States worth designing

  • Inbox empty after filters; show what people can do instead of leaving a blank panel.
  • Loading incidents without changing the layout unexpectedly.
  • Attachment or reply failed; explain the problem and preserve work.
  • Permission denied for alerts; clarify who can continue.
  • Success after choosing Create incident; confirm the result and the next step.
  • Network or data refresh failure; offer a retry without losing context.

Where this screen sits in the flow

Incidents → Alerts → Create incident → Review outcome

Patterns used

Inbox, Incidents, Alerts, Systems, accessible states, contextual actions

Why these choices work

Keep the active record close to its history, owner and status. Make urgent items easy to find without hiding the rest.

In this design, people should be able to compare Suspicious admin login with Credential leak detected. Make open clear, then use critical to explain whether the next step needs attention.

Before handing this to a designer or engineer, check keyboard focus, error copy, permissions and what happens after they choose the “Create incident” action. The happy path alone is not enough.

Related UI examples: Access Reviews, API Access, Audit Logs.

Start from this in Figr

Design a security incidents screen for our existing software product. Use our real design-system tokens, components and product language. Show Incidents and Alerts, include believable records such as Suspicious admin login, and make create incident easy to find. Map loading, empty, failure, permission and success states before you create editable high-fidelity screens.

Open Figr