Triage queue & email-in

Not every report arrives clean. Residents email the property manager, reports come in with no asset attached, and three people report the same elevator outage. The Triage tab is where staff turn that inflow into a tidy incident record.

The Triage queue

/admin → Triage lists the incidents that need staff attention, with the urgent stuff first:

• Untriaged incidents - email-sourced reports that have no asset or unit assigned yet (see below).
• SLA-breached incidents - anything past its acknowledgement target, already badge-flagged and severity-bumped by the sweep.

Each row has inline controls: assign an asset or unit, set severity, and acknowledge - without leaving the queue. The working rhythm is simple: keep this list empty. Acknowledging an incident stamps acknowledgedAt and stops its SLA clock; assigning an asset connects the report to the uptime record.

Email-in

CondoPulse accepts inbound email through a provider-agnostic endpoint: POST /api/inbound-email, guarded by Authorization: Bearer ${INBOUND_EMAIL_SECRET}. Any service that can turn an email into an HTTP POST works - Mailgun routes, SES + Lambda, Postmark inbound, or an n8n IMAP trigger → HTTP Request node. The payload is plain JSON:

{
  "from": "resident@example.com",
  "subject": "Gym door won't lock",
  "text": "The side door to the gym hasn't latched since Tuesday…",
  "html": "<p>…</p>",
  "attachments": [
    { "filename": "door.jpg", "contentBase64": "…", "contentType": "image/jpeg" }
  ]
}

What happens depends on the subject line:

Subject contains [INC-<id>] → appended as an update

An email whose subject includes an incident tag - e.g. Re: [INC-42] Elevator A2 stuck on floor 7 - is appended to incident 42’s timeline as an update. Attachments become incident photos (resized like any upload). This makes email a usable reply channel: vendors and residents can answer a notification email and their reply lands on the record.

Any other subject → a new untriaged incident

Everything else creates a new incident with:

• source: email
• title = the email subject
• description = the email body text
• severity = medium (a neutral default; staff adjust during triage)
• no asset or unit - email is the one source allowed to skip the “exactly one of asset/unit” rule, until triage
• attachments stored as photos

Untriaged incidents don’t pollute the status page’s uptime math (no asset yet) but appear at the top of the Triage queue. Triage means: read it, assign the right asset or unit, set an honest severity, acknowledge. From then on it’s a normal incident - SLA clock, followers, lifecycle and all. Like every mutation, inbound-email processing is recorded in the audit log (as the system actor).

Wiring example (n8n)

1. Email Trigger (IMAP) node watching issues@yourbuilding.example.
2. Function node mapping the email to the JSON above (file attachments → base64).
3. HTTP Request node - POST https://your-condopulse.example/api/inbound-email with header Authorization: Bearer <INBOUND_EMAIL_SECRET>.

Merging duplicates

Three reports of the same outage are good news (people use the system) and a bookkeeping problem (one outage, three records). Staff fix this with merge, on the incident detail page:

1. Open the duplicate incident at /incidents/[id] and choose Merge.
2. Pick the target incident - suggestions show incidents on the same asset or unit first, which is almost always where the true duplicate lives.
3. Confirm. The system then:
   • marks the dupe with mergedIntoId and closes it out,
   • copies the dupe’s reporter and followers to the target, so everyone keeps getting updates,
   • adds a timeline entry to the target - “Merged INC-x into this incident”,
   • records the merge in the audit log, and
   • makes the dupe’s page (and API responses) redirect to the target.

Merged incidents are hidden from default lists (pass includeMerged=true on GET /api/incidents if you need them). Merge direction matters: keep the incident with the better history - usually the earliest one with the accurate start time, since downtime math runs off the surviving incident’s interval.

Triage habits that keep the record clean

• Triage daily, merge immediately. Duplicates are easiest to spot while fresh; the AI intake assist (when enabled) also flags “possible duplicate of INC-x” right on the report form, reducing inflow.
• Severity on email reports is a guess (medium by default) - correct it during triage so SLA targets engage at the right level.
• Assign an asset whenever one fits. Only asset-linked downtime shows up in uptime bars and digest downtime hours; an incident left unit-less and asset-less is invisible to the metrics.
• Acknowledge as you triage. It’s one action in the queue and it’s the thing the SLA measures.