Audit Alerts
Access Prerequisites
- Permission (module):
viewAuditAlerts - License/Feature: None
- Menu container: GENERAL → group Audit
What it is / when to use
The Audit Alerts screen (/audit-alerts) centralizes alerts generated by the various microservices when a sensitive action or a suspicious pattern is detected — including behavioral anti-fraud for administrators (access from a new IP, high-velocity approvals, collusion between approvers, action outside business hours). It is the operational security triage "inbox."
Use this screen to review, assign, and close alerts: each alert has a status (pending, in progress, finalized), the source service, the action executed, and the descriptive message.
Prerequisites
- Permission: module
viewAuditAlerts. Permission is dual — CPM enum on the backend + dynamic module in the DB. - License/Feature: none.
- Dependencies on other screens: alerts are produced by the source services (AuditService and related). This screen only consumes and updates the handling state.
Step by step
- Open the menu GENERAL → Audit → Alerts.
- The table loads the alerts. Use Refresh to reload (shows a success confirmation).
- Click View details on an alert to open the handling modal.
- In the modal, set the status, record who is handling it (Handled by) and describe the resolution; save.
Filters and columns
| Filter / Column | What it shows | Data source |
|---|---|---|
| Status | Handling state: pending, in_progress, finalized | Alert status |
| Service | Microservice that originated the alert + actor identification (if any) | sourceService / actedBy |
| Action | Action executed that triggered the alert | actionExecuted |
| Message | Alert description | message |
| Created at | Creation date/time | createdAt |
| Actions | Opens the details/handling modal | — |
Fields (handling modal)
| Field | What it is | Required? | System/backend effect |
|---|---|---|---|
| Status | New state of the alert | Yes | Writes status; when finalized is chosen, sets resolved = true |
| Handled by | Identifier of the administrator responsible for handling | No | Writes actedBy; if filled in, sets acted = true. The modal fetches the user data (getUserById) to display the actor |
| Resolution details | Free text describing the investigation/decision | No | Writes resolutionDetails |
Actions and modals
- Refresh: reloads the alert list from AuditService.
- View details: opens the
AuditAlertDetailsModal. On successful save, the modal closes and the list is automatically reloaded.
Business rules / cautions
Caution
- Alerts for administrators (categories such as
isApprovalVelocityHigh,isApprovalPairRecurrent,isBulkActionBurst) indicate possible insider/collusion. Handle with priority and record the investigation in "Resolution details" — the field is the audit trail of the handling. - This screen does not execute the anti-fraud action (blocking); it records and organizes human handling. Emergency operational blocking is done via the Panic Button.
- Relationship with step-up / 4-eyes: the admin anti-fraud ADR provides for approval of sensitive actions by e-mail and step-up (password+MFA re-authentication). The alerts here are the detection/triage side of that flow.