Alert status model
Every alert moves through a defined set of statuses. This page describes what each status means, which actions are available, and what can prevent progress.
Labels below match what you see in the Quantavist app.
Status overview
| Status | Meaning |
|---|---|
| Unassigned | New or returned alert with no owner |
| Assigned | Delegated to a specific person; they must Accept before progressing |
| Accepted | Assignee has accepted responsibility; corrective work can proceed |
| Actioned | HSE user has recorded corrective measures; awaiting verification |
| Verified | A reviewer confirmed the action was appropriate — alert is closed |
| Discarded | Deliberately closed as not requiring safety action — alert is closed |
| Expired | Automatically closed after a period of inactivity; can be restored |
Open vs closed
Open alerts are actively being worked: Unassigned, Assigned, Accepted, or Actioned.
Closed alerts are finished: Verified and Discarded.
Expired is a special case — it is closed by the system but can be restored to the status the alert had before expiry.
Typical workflow
Most alerts follow this path:
Unassigned → Assigned → Accepted → Actioned → VerifiedA shorter path is available when you Assign to me from Unassigned — that skips Assigned and moves directly to Accepted.
stateDiagram-v2 [*] --> Unassigned Unassigned --> Assigned: Assign to someone Unassigned --> Accepted: Assign to me Assigned --> Accepted: Accept Assigned --> Unassigned: Decline Accepted --> Actioned: Action alert Actioned --> Verified: Verify Actioned --> Accepted: Reject Unassigned --> Discarded: Discard Assigned --> Discarded: Discard Accepted --> Discarded: Discard Unassigned --> Expired: Inactivity Assigned --> Expired: Inactivity Accepted --> Expired: Inactivity Actioned --> Expired: Inactivity Expired --> Unassigned: Restore (example)
Actions by status
Unassigned
| Action | Result |
|---|---|
| Assign | Alert moves to Assigned (chosen user must Accept) |
| Assign to me | Alert moves directly to Accepted |
| Discard alert | Alert moves to Discarded |
Assigned
| Action | Who | Result |
|---|---|---|
| Accept | Assigned user only | Moves to Accepted |
| Decline | Assigned user only | Returns to Unassigned (reason required) |
| Reassign alert | Users with permission | Stays Assigned with a new assignee |
| Request fix | Users with permission | Creates a fix request (see below) |
| Discard alert | Users with permission | Moves to Discarded |
Note: While an alert is Assigned, the assignee cannot Action alert until they Accept first.
Accepted
| Action | Result |
|---|---|
| Request fix | Creates a fix request for an engineer |
| Action alert | Records corrective action → Actioned |
| Reassign alert | Stays Accepted or returns to Assigned with new assignee |
| Discard alert | Moves to Discarded |
Actioned
| Action | Result |
|---|---|
| Verify | Moves to Verified (alert closed) |
| Reject | Returns to Accepted for rework (rejection comment required) |
The verify/reject step may be labelled Verify / Reject in the app. Assignees generally cannot verify their own actions unless they have a broader verification permission.
Expired
| Action | Result |
|---|---|
| Restore | Returns alert to its previous status before expiry |
Actioning an alert
Action alert records that corrective measures were taken on site. It is a multi-step process in the app:
- Review — confirm any submitted fix evidence
- Photos — attach evidence images where required
- Subcontractor — select the contractor responsible
- Description — provide an HSE comment describing what was done
Required inputs
You must provide:
- An HSE comment (action message) describing corrective measures
- A subcontractor
- Photo evidence when the workflow requires it
Do not action an alert without the information above — it forms part of the permanent audit record.
What blocks actioning
Outstanding fix requests are the most common blocker. You cannot action an alert while a fix request is still open in one of these statuses:
- Assigned
- Seen (in progress)
- Rejected
- Declined
The fix must be submitted, cancelled, or otherwise resolved first.
If a fix is Submitted, you can approve it as part of the actioning flow.
Other requirements:
- The alert must have an assignee
- You need permission to action alerts (or to action alerts assigned to you)
- You must Accept an assignment before actioning if the alert is still Assigned
Discarding an alert
Discard alert closes an alert without verifying corrective action. Use when the observation does not require safety follow-up.
You must choose a reason category:
- Authorised work permit
- Temporary safety controls in place
- Approved maintenance activity
- False positive
- Other (provide details)
You must also provide a comment or at least one photo.
Discarding cancels any open fix requests on the alert.
Fix requests (parallel workflow)
While an alert is Assigned or Accepted, an HSE user can Request fix to ask an engineer for on-site corrective evidence. Only one active fix request is allowed per alert at a time.
| Fix status | Meaning |
|---|---|
| Assigned | Engineer assigned; work not started |
| Seen | Engineer has opened or started the fix |
| Submitted | Engineer has submitted evidence |
| Accepted | Fix accepted when the parent alert is actioned |
| Rejected | HSE rejected the submission; engineer can resubmit |
| Declined | Engineer declined the assignment |
| Canceled | Fix no longer required |
| Paused (Alert Expired) | Temporarily suspended because the parent alert expired |
The Corrective action section on the alert detail page shows the combined progress of the alert and any linked fix.
Expiry and restore
Expiry
If an alert has no activity for a configured period (typically five days), the system automatically moves it to Expired.
When an alert expires:
- Its previous status is saved so it can be restored
- Any active fix request is paused (not cancelled)
- Escalation notifications for the alert stop
You may receive a reminder before expiry if your organisation has that configured.
Restore
Restore returns an Expired alert to the status it had before expiry. If a fix was paused due to expiry, it is restored to its prior fix status as well.
List views and filters
The alerts page groups work into views that map to statuses:
| View | What it shows |
|---|---|
| Unassigned alerts | Alerts with no owner |
| My alerts | Alerts assigned to you, with personalised status labels |
| In progress | Unassigned, Assigned, Accepted, and Actioned |
| All this week | Includes recently Verified and Expired alerts |
| Expired this month | Expired in the last 30 days |
By default, closed alerts (Verified, Discarded, Expired) are hidden so you can focus on open work.
Response metrics
The alert timeline may show:
- Time to effective action — from detection to the corrective action that was later verified (see Analytics)
- Time to assign — how long until someone took ownership
- Time to accept — how long until the assignee accepted
- Time fix/action — duration of fix work or actioning
- Time to verify — how long until verification
Some alerts show Verified by Quantavist Intelligence when verification was performed automatically.
Permissions summary
Not every user can perform every action. Common permission boundaries:
| Action | Typical requirement |
|---|---|
| Assign to others | Assign alert permission |
| Assign to self | Self-assign permission (auto-accepts) |
| Discard | Discard permission (may be zone-scoped) |
| Action | Action permission, or action-if-assigned when you are the assignee |
| Verify / Reject | Verify permission; assignees usually cannot verify their own work |
| Request / manage fixes | Evidence request management permission |
| Restore | Restore permission |
If an action is missing, check your role with your administrator.