Following & verified fixes

CondoPulse doesn’t consider an incident finished when staff say it’s fixed. It’s finished when a resident says it’s fixed. This page covers the two mechanisms that make that work: following (so you hear about every change) and the verified-fix loop (so you get the last word).

Following an incident

Following means you’re notified whenever an incident changes. You follow an incident in two ways:

• Automatically - when you report an incident, you follow it. No extra step.
• By merge - if your report is merged into another incident as a duplicate, you’re moved over as a follower of the surviving incident. You keep getting updates even though your original report is closed.

Any signed-in resident can also follow an incident they didn’t report - useful when the broken thing affects you too (“Elevator A2 down” matters to everyone in Tower A).

What notifications you get

Followers are notified on these events:

Event	When it fires
incident.status_changed	The incident moves through its lifecycle - acknowledged, in progress, resolved, verified, or reopened
incident.sla_breached	The incident sat unacknowledged past its severity’s time target and was auto-escalated
incident.merged	The incident was merged into another (you’re carried to the target)

Delivery channels:

• Push notifications on the mobile app - opt in once under Settings and your device is registered. See The mobile app.
• The incident timeline - every change is also a visible entry on the incident page at /incidents/[id], with who did what and when, so you can always catch up there even without push.

(Email notifications go to board/manager/admin users on SLA breaches; resident notifications are push + in-app timeline.)

The incident timeline

Open any incident at /incidents/[id] and you’ll see, newest activity at the top of the history:

• The status, severity chip, the asset or unit it’s about, who reported it (or “Anonymous resident”), and when.
• An SLA breached badge if it blew past its acknowledgement target.
• Every update: comments from residents and staff, status-change entries (“marked in progress”), merge notes (“Merged INC-14 into this incident”), and photos.
• You can add a comment yourself - extra detail, “still happening as of this morning”, a photo of the current state.

The verified-fix loop

Here’s the part that keeps everyone honest. The lifecycle is:

open → acknowledged → in_progress → resolved → verified

Resolved means staff believe the work is done. Verified means a resident confirmed it. After an incident is marked resolved, two buttons appear on the incident page (and in the mobile app) for any signed-in resident - with the original reporter front of the queue, since they know best whether the problem is actually gone:

• Confirm fixed → the incident becomes verified. This is terminal: the loop is closed, followers are notified, and the verification shows up in the building’s stats (the home page banner counts recently verified fixes, and the board’s weekly digest reports verified counts).
• Still broken → the incident goes back to in_progress. No new report needed, no starting over - the same incident, same history, same followers, reopened. Staff are notified that the fix didn’t take.

Both actions are recorded in the audit log with your name and a timestamp, and both notify everyone following the incident.

Why bother confirming?

• It closes the loop with evidence. A verified incident is a stronger record than a resolved one - it says the fix was checked by someone it affected.
• It keeps the stats meaningful. Boards watch the new/resolved/verified counts weekly. A pile of resolved-but-never-verified incidents is a signal worth seeing too.
• It takes one tap. If the elevator works again, tap Confirm fixed next time you’re in the app.

What if I disagree later?

Verification happens on resolved incidents. If a problem comes back after an incident is verified, report a new incident - the asset’s history will show the pattern (and the recurrence will be visible in the 90-day bar and the asset’s health stats, which staff review).

SLA breaches - what that badge means for you

You don’t have to chase anyone. Each severity has a time-to-acknowledge target: critical 4 hours, high 24 hours, medium 72 hours, low 168 hours (one week). If your report sits in open past its target:

1. It’s flagged SLA breached - the badge shows on lists and the incident page.
2. Its severity is automatically bumped one level (once, at most), so it sorts higher in staff queues.
3. Board, manager, and admin users are emailed, and followers - including you - are notified.

The escalation is automatic and logged. The system nags so you don’t have to.