Report App

The TrailsIQ Report App is the trail-user-facing side of TrailsIQ. It runs at app.trailsiq.com/report (any modern phone browser) and as a Capacitor-wrapped iOS + Android app installable from the App Store / Play Store. There's no login or account required. A hiker, mountain biker, or nordic skier opens it on the trail, taps "Report an issue", and their report lands in your moderation queue within seconds.

This article covers the app itself. For the manager-side pipeline (moderating incoming reports, notifications to your crew, per-org spam settings), see the Public reports setup article — same feature, different lens.

What the report app does

Four things, in decreasing order of what most trail users do:

1. File a maintenance report against a specific trail. A GPS-required wizard walks them through picking the org + trail (or letting the app auto-pick based on their location), tagging an issue type (blowdown, trail damage, missing signage, etc.), dropping a pin at the exact spot, snapping a photo, and adding a short note. Reports land in your moderation queue as pending review.

2. Check current trail status for a saved organization. Tap into an org from the home screen or from a push notification and get a per-network list of trails with their condition (open / caution / closed), grooming state, and recent day-notes. Search filters trails within the org.

3. Favorite orgs to get push notifications. Once favorited, the user gets a push on their phone whenever a trail or network condition flips, whenever the org publishes a new daily-report post, and (optionally) whenever events run. Fully in the user's control — the settings sheet on each favorited org lets them toggle every push kind independently.

4. See upcoming events for a favorited org. Volunteer days, group rides, races. The events tab on the org status view lists the next 30 days with signup CTA where the org has enabled that feature.

The app is designed to be reach-into-pocket-with-cold-hands-and-file usable — every step has a big tap target, GPS acquisition is patient (up to 60 s), photo capture is Camera-first (not a slow file picker), and the composer works fully offline against local trail data so a spotty forest connection doesn't block a report.

The report flow

Five steps, each on its own screen. The wizard remembers what the user picked so a bail-out and re-open doesn't restart from scratch.

1. Pick the organization. Two paths — near me (uses the phone's GPS to sort organizations by distance) or search by name. If the user landed via a deep link (/report?org=your-slug), this step is skipped. Orgs your organization has opted out of the report app entirely never appear in either list.

2. Pick the trail. The org's public trails, sorted by distance from the user's current GPS fix. A visitor can search by name.

3. Pick the issue type. The picker shows the types your organization has enabled for the report app — the built-in defaults plus any custom types you've added under Settings → Issue types, minus any you've toggled off via that page's Show in report app switch. Each type carries an icon so the picker reads as visual, not text-heavy.

4. Task priority + safety triage. Two lightweight pickers — safety risk (no risk / minor / serious) and is the trail passable? — that seed the maintenance-issue payload so a manager triaging the queue can see at a glance whether a report needs an emergency response or can wait until Friday. Custom-field types with a schema on the org's Issue types settings render additional inputs here.

5. Location + photo + note. A map centered on the picked trail with a draggable pin the user can nudge to the exact spot of the issue, plus a segment-length slider for issues that cover a stretch rather than a point (blowdowns are usually points; erosion is usually a segment). Below the map: a "Take photo" button that opens the phone camera, a text field for a short description, and a "Report" submit button. GPS is embedded in the report payload so a manager approving it knows where the reporter actually stood.

Organization status view

When a hiker taps an org from the home screen (or from a push notification), they land on that org's status page inside the app. Three tabs:

• Conditions — the default tab. Rollup banner at the top summarizing the whole org ("all trails open" / "3 closed · 2 caution · 15 open" / "all trails closed"), then per-network trail lists with a condition + grooming pill next to each trail. Search filters within the org.
• Daily — most recent public day-notes from your crew (last 14 days), one card per post with the author, timestamp, body, and any attached photos. Same content the /hub/{slug} public page shows.
• Events — next 30 days of public events from your org calendar. Rows link into the event detail sheet with a signup CTA when signups are open.

The Conditions tab is gated by two settings your org controls (see Settings that shape the app below).

Favorites + push notifications

A hiker who reports on an org can tap the heart icon on the confirmation screen to favorite that org. Favouriting does two things:

• Adds the org to the home-screen list so re-opening the app skips search.
• Enables push notifications for that org. What kinds fire is opt-in per-org — the settings gear on each favorite exposes toggles for Trail conditions, Daily reports, and Events.

Under the hood, the app registers an APNs (iOS) or FCM (Android) device token when the user grants notification permission. The token is scoped per favorited organization, so somebody who favorites four organizations can turn each one's notifications on or off independently. Push payloads carry a deep-link path so tapping a lock-screen banner opens the app straight to the relevant screen (a trail flip opens the org status view scrolled to that trail; a daily-report push opens the Daily tab).

If pushes stop arriving for everyone at once rather than for one person, that is ours rather than yours — ask us and we will check it from our side.

Offline outbox

The report app is built to work in the woods where connectivity is unreliable. If a hiker files a report with no signal, the report goes into a local pending outbox. The composer confirms the report was queued (not that it was sent). When the phone regains signal — whether that's stepping back into cell range, hopping onto trailhead WiFi, or getting home — the outbox flushes automatically.

The home-screen header shows a "{N} pending" badge when there are queued reports. Tapping the badge opens the sync panel where the user can see each pending report and force-retry.

Reports older than 7 days at the time of sync refuse to sync (staleness rule — a report from a week ago about a trail hazard is usually no longer actionable). The user sees an error in the sync panel and can decide to file a fresh report instead.

Settings you control that shape the app

Every switch that changes what a trail user sees for your org lives in Settings. The relevant ones:

• Exclude from public report app (Public visibility section). Removes your org from the report wizard entirely — hikers won't see it in near me or search, /hub/{slug} returns 404, favorites can't be created. Your crew + the field app + the dashboard keep working normally.
• Show trail status publicly (Public daily report section). Master switch for the Conditions tab in the report app AND the /hub/{slug} public page. When off, both surfaces collapse to a neutral state — no trail conditions shown, no anonymous push notifications for status flips.
• Show trail status in the report app (Public daily report section, right below the master switch). Independent narrower opt-out. When off (with the master still on), trails still list in the report app so a hiker can pick one to file against, but condition + grooming pills disappear. Useful when you use the report app as a pure issue-intake channel but manage trail conditions on a different surface (a Facebook page, a static website, etc.).
• Public timeline kinds (Public daily report section). Allow-list of which event families surface on the Daily tab. Defaults to Weather summary and Crew updates (conservative). Adding more (trail flips, grooming updates, area status, lift status, maintenance items, new infrastructure) opens each family up to public visibility.
• Public trails (per-trail toggle under each trail's details). A trail with visibility set to private never appears in the report app's trail picker. Useful for internal test loops or trails temporarily closed to public reporting.
• Issue types (Settings → Issue types). The picker on step 3 of the report wizard is scoped to your organization — every type has a Show in report app toggle so you can hide specific ones (e.g. an org-only ops type your crew uses internally but that a hiker would never file). Custom types you've added show up too, provided they're toggled on. Hidden types still work for internal maintenance-task creation on the dashboard; the toggle only affects the anonymous public report app.

Common gotchas

• Reports don't republish on the public hub. A hiker filing a report shouldn't expect to see their photo on /hub/{slug} — the hub is a crew-published surface (day-notes + weather + trail status), not a hiker-generated feed. Public reports land as pending-review maintenance items in your moderation queue. Even after a manager approves one, its photo + description are never republished to the hub. A text event ("New maintenance issue opened on Owl's Ridge") may appear on the hub's Activity feed if you've added maintenance to the Public timeline kinds allow-list, but by default that kind is off, so nothing surfaces. Hikers see other hikers' reports nowhere — they only see the state of the trail (open / caution / closed) once your crew has acted on the underlying issue.
• Duplicates from the same session are silently deduped. If a user files a report, doesn't see it appear (because moderation), and files a second nearly-identical one, the second one enters the queue too. Your queue will show both — either merge them at review time or reject the duplicate. There's no automatic dedupe.
• Exclude from public report app is aggressive. It also turns off your public hub, favoriting, and every push a trail user could receive. Turn it on only when you truly don't want any hiker-facing surface for your org. If you just want to hide the Conditions tab specifically, use Show trail status in the report app instead.
• Push notifications require the native app. The /report web version can't fire pushes — mobile browsers gate that behind a very different permission model. A hiker who wants pushes needs to install the TrailsIQ Report app from the App Store or Play Store.
• Rate limits apply per IP. The report submit endpoint is capped at 5 reports per hour per IP. A trail-side wifi hotspot with 20 hikers on it might hit this if there's a coordinated group filing multiple reports; extras get soft-blocked with a "try again in a few minutes" toast, and the queued outbox retries automatically.

What's next

• If you're setting up your org for public reports for the first time, follow the Public reports setup article — it covers the moderation queue, notification wiring, and every setting under a broader "getting to first-report" lens.
• If you want to control WHICH updates flow to /hub/{slug} (day notes vs weather vs trail flips), see How to use the daily report.
• If you want to send an email to every hiker who has favorited your org (event announcement, seasonal open/close), that pipe doesn't exist today — the only channel is a public day-note post, which fires the Daily reports push to opted-in favouriters.