Skip to main content
Alerts is a lightweight, always-current view of chemical readings that need attention.

​
Purpose

Use this module to see which pools currently have a chemical reading outside the ideal range, without digging through the full Chemical Records list. Alerts are derived automatically from chemical record submissions — nobody creates them by hand.

​
Best for

  • a quick daily scan of “what needs attention right now” across all your locations
  • supervisors triaging warning/critical readings without opening every record
  • confirming that a corrective retest actually fixed the problem

​
What generates an alert

Every time a chemical record is saved, AquaOps evaluates each measured field against the pool’s chemical profile and compares the result to that pool’s currently open alerts (open = not yet acknowledged and not yet resolved):
  • A field that comes back balanced automatically resolves (fixed) any open alert for that field — a later good reading is treated as proof the earlier issue is over, whether or not anyone ever acknowledged it.
  • A field that’s newly warning_low, warning_high, critical_low, or critical_high — and doesn’t already have an open alert — creates a new alert.
  • A field that’s still breaching but at a different status than its open alert (e.g. warning_high retests as critical_high) closes the old alert (superseded) and opens a new one, so there’s never more than one open alert per pool/field at a time.
  • A field breaching at the same status as its already-open alert is a no-op — the ongoing issue doesn’t get a duplicate row.
  • A field the test didn’t measure, or one that came back missing or closure_required, is left alone. closure_required readings don’t generate an alert at all — those are handled entirely through the closure incident workflow off the chemical record itself, not through this list.
warning_low / warning_high map to Warning severity; critical_low / critical_high map to Critical severity.

​
Alerts list

Go to:
A banner at the top shows how many alerts are currently open. The list itself shows, for each alert:
  • time
  • location / pool
  • field
  • status (with the same status badge used on chemical records)
  • message (e.g. “Free chlorine is above the alert threshold”)
  • state — acknowledged time, resolved time and reason, or an Acknowledge action
Open alerts are sorted to the top, then everything is ordered newest-first. If the alert came from a specific chemical record, the row links straight to that record’s detail page.

​
Desktop vs. mobile

Desktop shows the full table described above. Mobile shows the same information as tap-friendly cards.

​
Acknowledging an alert

Acknowledging is a manual, one-way action: it stamps acknowledged_at and the acknowledging user, and the alert drops out of the “open” count. There’s no separate dismiss/reject action — acknowledgment is the only person-driven way to close an alert out. This is distinct from auto-resolution: an alert can also close itself out with a resolved_at timestamp and a resolved_reason of fixed (a retest came back balanced) or superseded (the same field breached again at a different status) — no person needs to act for that to happen. The list shows whichever happened: acknowledged time, or resolved time plus reason.

​
Notifications

If a user has Chemical alerts email notifications turned on (Settings > Notifications, on by default), they’ll get an email whenever a new alert is created — one email per chemical record’s worth of new breaches, summarizing all fields that broke on that test. Recipients are exactly the users who could already see the alert in-app: active users with chemical_records:view or org:manage, scoped to the alert’s location (an org:manage holder sees everything). Email delivery is best-effort — if it fails or is skipped, the alert still appears in-app regardless.

​
Permissions

  • Viewing the Alerts list requires chemical_records:view. Without it, the page shows a “you don’t have permission” message instead of the list.
  • Acknowledging an alert requires chemical_records:edit. Users who can view but not edit chemical records see the alert’s state but no Acknowledge button.
  • Alerts as a feature can also be turned off for your organization at the platform level. If it is, the page (and the Acknowledge action) show a “This feature isn’t available for your organization” message instead.

​
Typical walkthrough

1

Open Alerts

Check the open-alerts banner for a quick sense of how many issues are outstanding.
2

Review an alert

Read the message and, if it’s linked to a chemical record, open the record for full context.
3

Take corrective action

Address the underlying chemistry issue, then re-test the pool.
4

Let the retest confirm it

If the retest comes back balanced, the alert resolves itself as “fixed” — no action needed here.
5

Acknowledge if appropriate

If the reading is being tracked another way (e.g. a closure incident) or you simply want to mark it as seen, use Acknowledge.

​
Best practices

  • treat Alerts as a triage view, not a replacement for reviewing full chemical records
  • don’t rely on acknowledging as a substitute for actually re-testing — only a balanced retest closes the underlying issue
  • keep your chemical alert email notifications on if you’re responsible for a location, so you don’t have to keep the list open to notice new breaches
  • remember closure_required readings won’t show up here — check the compliance/closure workflow for those
  • review pool chemical profiles periodically, since alert thresholds come directly from them

​
Suggested screenshots

  • desktop alerts list with the open-alerts banner
  • mobile alert cards
  • an alert row with the Acknowledge button visible
  • an alert row showing an auto-resolved (“fixed” or “superseded”) state
  • the “you don’t have permission” empty state