TrailsIQ Go

TrailsIQ Go is the trail-user-facing side of TrailsIQ: a free app for iOS and Android, installed from the App Store or Google Play. It was called TrailsIQ Report until version 1.7, and a phone that has not updated yet still shows that name under its icon. Opening app.trailsiq.com/report in a phone's browser offers the download. No account is needed: 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. An account is optional, for the reporter who wants their name on what they send and wants to follow what happens to it — see Optional accounts below.

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 TrailsIQ Go does

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

1. File a maintenance report against a specific trail. A short wizard asks first whether they are standing at the spot or working from a photo they took earlier, works out which organization and trail the report belongs to, and asks for 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

Four steps, and the third often does not appear at all.

1. How are you reporting? Two cards. I am at the spot is the ordinary walk-up and goes to the camera. I took a photo earlier opens the phone's photo library on the tap and reads the location out of the picture, which is the path for somebody who is back at the truck or at their kitchen table with this morning's photograph of a washout. Either way the app starts asking the phone where it is the moment this screen appears, so the seconds spent choosing are seconds the location lookup was going to need anyway.

2. The photograph. On the I am at the spot path this is the camera, and a report cannot be filed without a picture — it is what your crew works from. The button says Take a photo first until there is one, then Use this photo. A reporter who came in through I took a photo earlier never sees this screen: the picture they chose is the report's photograph, so asking again would be asking for what they have already given.

3. Where. This screen only renders when it has a question. If more than one organization has a trail within range the reporter picks which one receives the report; if more than one trail is close, they pick the trail. If your crew already has an issue filed within about 50 meters, it is shown to them and they can confirm that one rather than file a second. If the fix is still coming in, the screen says so and shows the accuracy falling, with an option to use the location as it stands. When there is one organization, one trail and nothing already filed nearby, this step is skipped and the reporter goes straight to the last one.

4. What's going on? One description box and, if they want to leave it, their name. The photograph and the spot are already attached, and the screen says so.

The type and the pin are derived, not asked for. The coordinates are the fix the gate already took, or the ones saved inside the photograph — so a map asking them to agree with a pin under their own feet was a screen that could only cost them time. The title is the trail plus the first issue-type word the app recognizes in the description, so "big blowdown across the corridor" on Owl's Ridge arrives as Owl's Ridge — Blowdown, and a description with no recognizable word arrives under the trail's name alone. Which words count is exactly the list your Settings → Issue types page controls.

A bail-out and re-open does not restart from scratch.

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 are open" / "Most trails are on caution" / "17 of 20 trails open" / "All trails are closed", with a line under it such as "17 of 20 open · 2 on caution · 3 closed"). Caution counts as open, and the banner turns amber only when most trails are on caution or some are closed, the same reading as the daily report. 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.

Optional accounts

Everything above works with no account, and it stays that way. A trail user who wants more can sign in from the person icon in the app's bottom bar or from the menu. Signing in is an email address and a six-digit code we email them; there is no password. It is free, and it does not depend on your plan.

What changes for the reporter:

• Reports go under their name. On the last step of the wizard the app says Sending as and their name, with a Send without my name box for any report they would rather send anonymously.
• My reports. The account screen lists every report they sent under their name, with where it stands: Sent (waiting for your review), Accepted, In progress, Fixed, or Not added. A report's photo opens full size when they tap it.
• Notifications about their own reports. With notifications allowed, the app tells them when your crew accepts a report, starts work on it, marks it fixed, or turns it down.
• Workdays. Events they sign up for with the account's email show on the account screen, along with any they checked in at. Past workdays show the hours your organization credits them, by the same rule as your volunteer hours: they signed up as going, you have not unmarked them as came, and the event is over. If you change someone's time on the attendee list, their account screen shows the new figure.
• Checking in at a workday. On the event's day, Check in at a workday in the menu opens a scanner for the QR code the organizer shows. If the organizer set a check-in spot, the event's page in the app also offers Check in to anybody close enough, with no scanning. While an event's check-in is open, the home screen shows it as a card with its own Check in button, for every organization the person follows and for any event they signed up for, followed or not. A scan with no signal is saved on the phone and uploads once it is back in range. If your organization uses one main check-in code for all its events and two are open at once, the app asks which one. See Check-in from TrailsIQ Go in the events article for the organizer's side.
• Earlier reports come along. The first time somebody signs in on a phone, the reports that phone already sent are added to their list. You are not told those were theirs; they arrived anonymously and stay that way on your side.
• They are asked once a report is sent. Somebody who sends a report without an account sees Follow this report on the confirmation screen, with Create an account and Not now. Making one from there puts the report they just sent in their list, including one still saved on the phone waiting for a signal: it goes into the list when it uploads. As with earlier reports, it reaches you exactly as it was sent, with no name or email added.

What changes for your crew:

• You see the reporter's name and email on a report sent from an account, under Reporter on the task, in the dashboard and in the field app. The email is a link, so a question about a report is one tap away. Reports sent without a name look exactly as they always have.
• Rejecting asks for a reason, and the reason is optional. When you reject a report, the dashboard and the field app ask why. Leave it blank to reject without one. If the reporter sent it from an account, they see your reason next to Not added; nobody else does. Cancel backs out of the reject.
• An account is not a membership. A reporter with an account does not appear on your Team page, does not take a seat, and cannot see anything in your workspace. If you want one of your regular reporters on your crew, invite them from Team like anybody else, using the email address on their reports.

A reporter can delete their account from the account screen at any time. Their earlier reports stay in your maintenance list with the name and email removed. Event signups and check-ins stay on your attendee lists as they are, the same as a name on a paper sign-in sheet.

Offline outbox

TrailsIQ Go 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 TrailsIQ Go (Public visibility section). Removes your org from the report wizard entirely — hikers won't see it in near me or search, favorites can't be created, and no notifications go out. Your /hub/{slug} page stays up; it has its own switch, Hide public hub page, right below. Your crew + the field app + the dashboard keep working normally.
• Show trail status publicly (Public visibility section). Master switch for the Conditions tab in TrailsIQ Go 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 TrailsIQ Go (Public visibility section, right below the master switch). Independent narrower opt-out. When off (with the master still on), trails still list in TrailsIQ Go so a hiker can pick one to file against, but condition + grooming pills disappear. Useful when you use TrailsIQ Go 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 TrailsIQ Go's trail picker. Useful for internal test loops or trails temporarily closed to public reporting.
• Issue types (Settings → Issue types). Trail users are not shown a picker any more, but this list is still what TrailsIQ Go reads: it is the vocabulary the wizard matches a description against to title the report. Every type has a Show in TrailsIQ Go toggle, so a type you keep for internal ops will never be pulled out of a hiker's wording, and a custom type you have added will be. Hidden types still work for internal maintenance-task creation on the dashboard; the toggle only affects the anonymous TrailsIQ Go.

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.
• A second report of the same thing is not merged for you. 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 TrailsIQ Go is broad inside the app. It also turns off favoriting and every push a trail user could receive. It leaves your public hub alone; to take that down too, turn on Hide public hub page as well. If you just want to hide the Conditions tab specifically, use Show trail status in TrailsIQ Go 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 TrailsIQ Go 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.