Reporting an incident from the phone
What a worker taps, who finds out, and what has to be set up first so the report reaches a person rather than a log file.
What the worker does
From the app's home screen: Report an incident. They pick which site it happened at, describe it, set when it happened, optionally attach photos, and send.
They do not land back on the home screen with a "sent" message. They land on the wellness page — who to ring at the office, the national crisis numbers, and what the next fortnight may feel like. That page is a workspace's own: edit it at Admin → Pages, slug wellness. If a workspace has not written one, the app shows the built-in crisis numbers rather than nothing.
Who gets alerted
A chain, most specific first, taking the first level that answers. Everyone at that level is emailed, on one message. Told separately, four people each assume another has it.
| Level | Who | When it applies |
|---|---|---|
| 1 | Supervisor (client side) the person at the site | The placement names one. |
| 2 | Consultant (our side) the recruiter looking after the placement | No client supervisor named — or the report is about them. |
| 3 | The placement's group / division, everyone in it | Neither of the above, and the placement's group is a real division rather than the workspace's catch-all. |
| 4 | Every internal user in the workspace | Nothing more specific is set. Also where a catch-all group such as "All Users" lands, because it means the same thing. |
The incident is assigned to the first name at that level, because somebody has to own it, and reported by the worker. Both are real links, so the incident is navigable from either person.
Why the consultant is separate from the supervisor
The site supervisor can be the reason there is an incident. A report about them, addressed only to them, is not a report. Naming a consultant means the agency hears regardless of what happened at the site — and if the client supervisor is blank, the consultant is told instead of a stranger.
There is no "nobody" any more
The chain used to end at a single fallback — the lowest person id with a login, which is not a role but an accident of who was created first, and who may have left. It now ends at every internal user. A workspace that reaches level 4 is one where nothing was configured, and the answer to that is to tell everybody rather than to guess.
The one remaining silence is a workspace where nobody has an email address. The report is still stored; the log records which level was reached and why, so it is clear whether the placement is misconfigured or the workspace is.
One thing that behaves differently to timesheets
The placement form's blank supervisor means "use the site's nominated supervisor(s)" for timesheet approval, which falls back through site_nominations. Incident alerting does not consult site nominations — it goes supervisor, consultant, group, everyone. If a site's supervision is set up only as a nomination, name a consultant on the placement so level 2 catches it.
Setting it up
- Name a consultant on the placement. Placements → the placement → Consultant (our side). This is the single most useful field: it puts a named person at your end on every incident from that placement, whatever the client has or has not set up.
- Name the client's supervisor too, where there is one. Supervisor (client side). They hear first.
- Set the placement's group to the right division. When neither person is named, the whole division is told — so "TGP – QLD" reaches the Queensland team rather than everybody.
- Give those people email addresses. A chain that resolves to people with no email means the report is stored, a warning is logged, and nobody is told.
With a placement, and without
A worker can report an incident whether or not they have a placement. A new starter sent to an induction has installed the app before the recruiter has written their placement — and that is exactly when something can go wrong on the drive. Requiring a placement would turn that person away.
| With a placement | Without | |
|---|---|---|
| Can report | Yes | Yes |
| Who is alerted | Supervisor, else consultant, else the division | Straight to level 4 — every internal user, since there is no placement to read |
| Linked to a site | Yes, the client organisation | No. The office can attach one afterwards |
| Site in the email | Named | Omitted |
| Owned, assigned, attributed | Yes | Yes — all three are recorded either way |
In the app, a worker with placements also gets “Somewhere else — not at one of these sites” in the site picker, for an incident on the drive, at an induction, or between jobs.
What the alert contains
Subject names the incident. Body carries the reporter, when it happened, priority, site (where there is one), the workspace, the location as typed or the GPS fix, how many photos were attached, and a link straight to the incident in the CRM.
The email is sent outside the database transaction and on a best-effort basis. A mail outage can never lose a report that has already been stored — the incident is on the record first, and telling somebody is a separate step that is allowed to fail.
What the worker can see afterwards
My reports & support on the app's home screen lists everything they have reported — what they wrote, when, the site if there was one, and how many photos. Status shows as With the office or Closed and nothing finer: how a report is being handled is not the worker's to read.
The same screen carries the support page as a button at the top, so it can be reached on a quiet evening three weeks later without filing anything to get to it.
Where it lands
Incidents appear in the CRM under Incidents, in the workspace the worker was signed in to. Somebody who belongs to several workspaces should check the workspace picker before concluding a report has gone missing: the record is in the one the app was on when it was filed, not the one the browser is looking at.