Triaging reports from the public
Verify what the public sends you, turn it into a task or refuse it, and group in one go the reports describing the same problem.
A public report is not a task. It is information to verify.
The distinction sounds academic; it is very practical. If every report became a task, your board would fill with duplicates, false positives and already-fixed problems — and you would spend your evenings cleaning up. Reports therefore arrive in a separate inbox, and nothing enters your planning until someone decides it should.
Where: left navigation bar → Reports. On mobile: the Reports tab of the inbox.
The inbox
On opening, you see every untriaged report received, whatever the year. That is the default: what is waiting for a decision.
The inbox, list view.
- 1Three views of the same content: list, board, map.
- 2The filters: by status, and by year.
- 3Status reads as a step bar, not a coloured pill.
- 4The trail link, guessed by the app and confirmed at triage.
Status is a progression, not a label. Four steps: received, accepted, in progress, resolved. The bar fills as the problem moves along, which scans in one glance down a whole column. A refused report leaves the progression and turns grey.
The three views serve different moments:
| View | When |
|---|---|
| List | Daily triage. Everything is comparable line by line |
| Board | Seeing where the season stands. Columns follow the four steps, and the board is always on the current year |
| Map | Spotting clusters. Five reports in one place show up immediately |
In board view there are no filters: the columns already filter. The closed column shows nothing by default — a button in the top menu brings them up when you need them.
Triaging a report
Click a row: a panel opens with everything you need to decide.
The triage panel.
- 1The position, on the map, with the guessed trail highlighted.
- 2The other reports waiting at the same spot.
- 3The trail link, to confirm or correct.
- 4The two outcomes: refuse, or turn it into a task.
You have three possible outcomes, no more.
Turn it into a task. The button opens your usual creation form, already filled with the report's position, trail, activity, description and photos. You complete the type and the priority — what the public did not tell you — and save. The report stays linked to the task and follows its progress on its own.
Attach it to an existing task. Often the right move: someone reports a problem you already know about. The report's photos are added to the task, and the reporter is told work is planned. If the task is already finished, they are told it was already fixed — which is a real answer, not silence.
Refuse it. Outside your network, a duplicate, or simply not a problem. You can enter a reason and choose to share it with the reporter. Share it: "this trail is not ours" prevents the next five reports.
The trail link matters more than it looks. It is what makes the task appear in the right trail's reports. The app offers the closest trail; when there are several candidates, it lets you choose rather than guessing.
Grouping what repeats
A tree across a busy trail gets reported three times before noon. Handling all three separately means creating three tasks for one tree.
When you create a task or attach one, the app shows you the reports waiting at the same spot and lets you choose which ones come along.
Selecting neighbouring reports, at the moment of creating the task.
- 1Nothing is pre-checked.
- 2The second row is about a rock, not a tree: nearby does not mean the same.
- 3Select all, when it is obviously the same problem.
- 4Continue then opens the task form, as usual.
Why nothing is pre-checked. Two reports twenty metres apart can be a fallen tree and a rock in the descent. Include the wrong one and its reporter will receive "in progress" then "resolved" for a problem that is not. The cost of a mistake is carried by a trail user, not by you: that is why the box is empty, and why every row shows its photo, its description and its age.
The window is deliberately narrow: reports within 40 m and less than 72 h old. Beyond that, two reports in one place are probably two different problems, or the same problem reported two seasons in a row.
Only untriaged reports appear. A neighbour already accepted, in progress or resolved is not in the list: there is nothing left to decide about it.
With no neighbours, nothing changes. The selection screen does not appear, and "Create task" opens the form directly.
In the field
Full triage is available on mobile, with the same logic and the same outcomes. Neighbour selection there is a full screen, presented when you tap Create task or Attach:
Neighbour selection on mobile.
- 1Select all, in the header.
- 2One row per neighbour, with its photo and description.
- 3Continue carries on to task creation, or to the attach confirmation.
Triaging from the field has a real advantage: you are standing in front of the problem. You can see whether the three reports are about the same tree, which no photo will ever tell you as well.
Who can triage
Two distinct permissions, on purpose:
| Permission | What it opens |
|---|---|
| Reports (read) | Seeing the inbox |
| Reports (read-write) | Triaging: accept, refuse, create, attach |
| Report settings | The administration page, the QR code and the code |
A volunteer can therefore watch reports arrive without being able to decide, and a lead can triage without being able to change the network's openness. The full role breakdown is in Understanding roles.
What it looks like on the dashboard
The dashboard counts three figures over the chosen period: reports received, closed and refused, with their change against the previous period and a histogram of receptions per day.
The ratio between "closed" and "refused" is the measure that counts. If it tilts toward refusals, your users are reporting off-topic — often because your network's zone is set wrong, or because your trailhead sign is in the wrong place.