How field reports work

Operators are usually the first to find out that a procedure is wrong, because they are the ones standing in front of the situation it describes. A field report is how that knowledge gets back to the people who can fix the content. By the end of this page you will know where a report travels, which check decides whether it counts, who is told, and why the operator never hears what was decided.

It starts on the phone, with or without signal

At the bottom of every article, checklist, quiz, video and audio item, the app offers Flag an issue with this content. The operator picks one reason — Out of date, Incorrect, Unclear, Safety concern or Other — can add a note of up to 2,000 characters, and selects Report issue. A guide's own page has no flag: operators flag the items inside it.

The report is saved on the phone first and joins the queue of the operator's other offline actions, which the app replays when it comes back to the foreground and at every sync. Until it goes, the item reads "Issue reported — sends when you’re back online." Each report carries an id made on the phone, so a replay that repeats itself cannot create a second copy. See how the offline queue works.

The database decides whether it counts

When the report reaches ROK, a database function records it — and it accepts a report only when the item is still published in the agency the operator is signed in to, and the operator is a member of that agency. Anything else is quietly ignored rather than refused, so a stale report can never jam the operator's queue.

The case that matters is an item that was unpublished while a report sat on a phone. That report is not recorded anywhere, and nobody is notified.

Who is told

A recorded report lands in Field reports (opens the admin console) as open. At the same moment, everyone who holds Edit content gets a bell notification — "An operator flagged an issue on “…”" — that opens Field reports. Field reports are also emailed by default: each person can switch that off in their own notification preferences, and anyone who reads the notification in the console within about a minute is not emailed about it. See Notifications.

Only the first open report on an item rings the bell. While one report on an item is open, more reports on the same item arrive in the list silently, so a burst of reports about one bad checklist doesn't flood everyone's notifications. Once every report on the item has been closed, the next one rings again.

Closing a report and fixing the item are separate acts

Resolve means you acted on the report; Dismiss means no change was needed. Either one closes the report and records who closed it and when — and changes nothing else. The buttons appear for people who hold Edit content.

The correction happens in the item itself, in the editor. Operators then receive the corrected version the way they receive any published change: at their next sync. See how publishing works.

What the operator sees afterwards

Very little:

• On their phone, the item keeps showing the status of their most recent report on it — "Issue reported — your content team has been notified." — whatever you later decide.
• The app never shows whether a report was resolved or dismissed, or by whom.
• If you change the item, they see the new version after their next sync, like everyone else.

If the outcome matters to the person who reported it — and for a Safety concern it usually does — tell them yourself.

In practice

• Reports can arrive late. The When column in Field reports is when the report reached ROK, not when it was made on the phone, so a report from a weekend in a gorge can show up on Monday.
• Nothing closes a report for you. Editing or unpublishing the item leaves its reports open until someone resolves or dismisses them.
• Watch the trend, not just the list. The dashboard's Field reports widget summarises open reports by reason, with the age of the oldest — see the dashboard reference.