How to create a maintenance item

Maintenance items — internally called maintenance issues — are how you track everything that needs doing on a trail: downed trees, erosion, broken bridges, faded signage, drainage failures. Every crew member (and, if you enable it, every trail user) can file one, and the dashboard runs the queue.

What is a maintenance item?

A maintenance item is one task on one trail (or one point on the map). Every item carries a title, a description, coordinates, a status, and a priority. Optional links tie it to a specific trail, structure (bridge / kiosk / boardwalk), climbing route, lift, or maintenance project so a "fix the bridge on the North Loop" task can be found from either direction.

Every item also carries an audit trail: who filed it, who changed its status, who added photos, and when. That log is permanent — even a deleted item's history is retained for legal + accountability reasons.

It also carries a discussion — the place for what the audit trail cannot hold: what you found when you got there, what you tried, and what it will take. See Discussing a maintenance item.

There is no assignee. Items aren't handed to a specific crew member; the queue works pull-style — anyone with the right role opens the list, filters, and picks work. If you want personal-assignment tracking, use Projects to group items and assign the project.

Statuses and priorities

Every item is in one of four statuses:

• Open — filed but not started. This is the default for anything a crew member files.
• In progress — someone's actively working on it.
• Resolved — done. Kept, with its history, and included in reports.
• Pending review — filed anonymously by a trail user via TrailsIQ Go; hidden from the main map + list until a manager approves or rejects.

Items also carry a priority: Critical, High, Medium (default), or Low. Priority is display metadata — it filters and sorts but doesn't gate anything.

How open items age visually

Open items age on the map + in every list so a month-old backlog reads differently from a task filed this morning. The color ramps through five weekly buckets:

• This week (0–6 days) — green. Label reads NEW.
• 1 week old (7–13 days) — yellow. Label flips to OPEN.
• 2 weeks old (14–20 days) — orange.
• 3 weeks old (21–27 days) — red.
• 4+ weeks old (28 days and up) — deep red.

The scale applies to open items only. Once someone picks up a ticket (status flips to In Progress) the marker turns blue regardless of age — an ancient item finally getting worked doesn't stay red. Resolved items ghost out to gray, and Pending review also uses gray.

On the field app, a small color legend sits under the Status filter chips on the Maintenance filter page — same buckets, same colors. The marker on the map, the status pill on the list row, and the chip on the horizontal task-card slider all track the same scale, so you can scan any of those surfaces and immediately know how stale the backlog is.

Creating one from the field app

On the mobile field app, tap the Maintenance tab, then hit the big + floating action button in the bottom right. The label reads "Create New Task".

The wizard walks you through:

1. Issue type — pick from the chips: Blowdown, Water, Erosion, Drainage, Signage, Surface, Overgrowth, Broken structure, Trash, Hazard, Service / Repair, Other (plus climbing-specific types if your organization has climbing enabled). Picking Broken structure asks you which structure later on.
2. Location — the app defaults to your GPS fix; you can drag the pin to correct it if you're off the trail. The trail is auto-detected from proximity, and for most types you need one before you can go on: a task with no trail is missing from that trail's own list of open work.
   Service / Repair is the exception. It is work on something you own rather than on a stretch of trail — a machine sits in a shed, on a trailer or in somebody's yard — so a pin on its own is enough. You still have to drop one, because a task with no position never appears on the map.
3. Photos — capture or pick photos from your camera roll. Optional but strongly recommended — the person doing the work needs to see what they're walking to.
4. How bad is it? — two questions, is anyone likely to get hurt and can people still get past, which together set the priority. Under the answer is a Warn the public switch, off unless you turn it on and not offered when the answer is No risk — see Warning the public about a hazard. Skipped for Service / Repair, because neither is answerable about a machine: that type starts at Medium and the priority can be changed on the task afterwards.
5. Details — Title (optional), Project link (optional), Structure link (only when you picked Broken structure), Description ("What's going on?"), and The work — hours, people, tools and materials, all optional. The priority is the previous step's answer; to change it after filing, open the task and edit it.

Submitting queues in the app's offline outbox if you're not connected. Photos upload separately after the item is created.

Starting from a machine is shorter. Log service or repair and Report a problem on an equipment item open the same wizard with the type already set, the machine attached, and the where and the how-urgent steps left out — both were answered by the row you tapped, and the pin comes from the machine's home location.

Creating one from a climbing route

If your organization has climbing enabled, every climbing route has a Report issue button on its detail card. Tapping it deep-links to the web maintenance form with the route link, coordinates, and default issue type pre-filled — you just add a title and description and hit save.

Route-linked items show up on the route's own maintenance list too, so anyone looking at the route sees them alongside its stats and photos.

Public reports from trail users

If you've turned on public reports in Settings, trail users can file issues via TrailsIQ Go at /report — no account needed. The wizard has four steps:

1. Issue type
2. Confirm the spot on the map
3. Photos (optional)
4. Issue details — Title, Description, "Your name (optional)" (default: Anonymous)

Every public report lands as pending_review. It doesn't appear on the public map, in the main list view, or on the trail's detail page until a manager approves it. This is the moderation gate — see the pending-review queue section below.

Managers get an in-app notification the moment a public report lands. If they've opted into the Public reports email preference, they get an email too. The count of pending items shows as a red badge on the Maintenance sidebar entry.

Every field on the create form

The field-app wizard captures every field an item can have, broken across its four steps. Public reports expose a smaller subset. All labels below are the same ones you'll see on screen.

• Title — optional, plain text (placeholder: "Downed tree at junction"). What shows in the list and on notifications. Left blank, the wizard auto-fills a short label from the issue type and trail so you always see something readable in the queue.
• Description — optional but strongly recommended. Detail on what's wrong, what's needed, and any context. The field for the person doing the work — the more context they have, the fewer round-trips to figure out what tools to bring.
• Trail — optional dropdown. Default: "— not on a specific trail —". Items without a trail land on the general maintenance list; items with a trail also appear on the trail's Show page.
• Type — a picker of chips. The ones every organization starts with are Blowdown, Water / Mud, Erosion, Drainage, Signage, Tread Repair, Clear Corridor, Broken Structure, Machine Work, Adaptive Improvements, Trash / Litter, Hazard / Wildlife, Service / Repair and Other, plus four climbing ones when climbing is turned on. You can add your own, rename any of them and decide which appear in TrailsIQ Go, under Settings → Issue types. Picking Broken Structure reveals the Linked structure field.
  • Broken Structure and Service / Repair are not the same question. The first is this is broken; the second is this is ours to keep running — a gate that no longer latches, a kiosk panel, a machine due a service. An incident against an interval, and filing the second as the first loses the difference the moment it is filed.
  • Machine Work, Adaptive Improvements and Service / Repair start hidden from TrailsIQ Go. Somebody walking past has no way to judge whether a machine is due a service, and a choice a reporter cannot judge is one that collects guesses. Turn any of them on in the same settings screen.
• Priority — dropdown: Critical / High / Medium / Low. Default: Medium.
• Linked climbing route — dropdown (only visible when your org has climbing). Pre-filled when you come from a route's "Report issue" link.
• Linked structure — dropdown (only when Type is broken_structure). Ties the item to a bridge, kiosk, or other on-trail structure so it shows on the structure's own detail page.
• Latitude / Longitude — required. Auto-filled from the map picker or your GPS on the field app. Manual entry is fine too for a deskbound builder logging something reported by phone.
• Location source — manual or gps. Recorded so reports later can tell "operator dropped a pin" vs "we captured this from a phone".
• Reporter — optional. The name of whoever spotted the issue. The submitter is always recorded (the logged-in user, or "Anonymous" for public reports) — this field is for a different name (e.g. a caller who phoned it in).
• Est. hours and Crew · people — optional, under The work. How long the job runs and how many people it wants at once; the app multiplies them into person-hours under the two boxes. Leave one blank and it says so instead of showing a zero — a job with no estimate and a job estimated at nothing are different rows on a planning screen.
• Tools needed and Materials needed — optional lists, also under The work. + Add tool and + Add material open a sheet over your inventory: search it, filter by category, tap a row to add it, and use the stepper for a quantity. Anything you type that is not in your inventory is added as its own row and labeled Free text, so the list is never blocked on somebody having cataloged a saw. Adding a tool here does not reserve or move any stock — it is a packing list, not a checkout.

What happens after you file

• An audit row is written with kind created, timestamping who filed the item and when. Same audit log records every future status change and photo add.
• If the item came in as pending_review (public report), every active owner + manager gets an in-app notification. Those who've opted into the Public reports email preference get an email too.
• If the item came in as open (any authenticated flow), no notification fires — the item appears in the Maintenance list, and the crew picks it up when they're next scanning the queue.
• Any status change afterwards fires an org-wide activity event — visible in the activity feed and, for members who've enabled it, delivered via push notification and email.

Editing and status changes

Open the item's Show page and click Edit in the top-right, or hit the pencil icon on the list row. What you can edit depends on your role:

• Managers and owners — every field. Title, Status, Priority, Type, Trail, Project, Linked structure, Description, Reporter.
• Field workers — only the Status dropdown, and only two options: In progress or Resolved. There's a note on the edit page that reads "Field workers can only mark issues as 'in progress' or 'resolved'." If a field worker needs to change a title or reassign, ask a manager.

Quick status change — every list row has inline status buttons for one-click In progress / Resolved transitions. Open is manager-only: a field worker can't reopen a resolved item, which takes a manager.

The detail panel — click an item in the Maintenance list and it opens on the right, with three tabs:

• Details — the description, the trail, when it was reported, where it is, any linked structure, and its photos. + Add photo adds pictures from your computer. A manager can take one off again with the ✕ on its corner.
• Discussion — the conversation about the work. See Discussing a maintenance item.
• Work log — the time spent on it. Log a session with its date and minutes, and tick anybody who worked it with you; each person gets their own entry for the same time. If the item is linked to a volunteer workday, the workday is listed at the top with the hours it has already counted, and the form warns you before you log the same day again for somebody it already counts.

Along the bottom, Mark complete finishes the item in one click, and anybody on the crew can press it. A finished item shows Reopen instead, which is for managers. Edit details opens every field for a manager, and Delete removes the item.

Pending-review items have their own controls on the Show page:

• Approve — flips the status to Open, adds it to the main queue, and clears the pending-review notification. Confirms with "Approve this report and move it to Open?"
• Reject — permanent delete. Confirms with "Reject and delete this report? This cannot be undone." Attached photos are deleted with it, and every notification referencing the item is cleaned up.

The work — hours, people, tools and materials — is edited on the phone, from the task's own Edit screen in the field app, and it sits there in exactly the shape the wizard used. On the web it is shown on the task rather than edited: open the item and it reads back under The work, so whoever is scheduling the week can see what to put in the truck without opening a form.

Regular status changes (open ↔ in_progress ↔ resolved) can also happen via the field app's Maintenance tab detail sheet — same permissions apply.

Warning the public about a hazard

Trail status says whether a trail is open. It cannot say "open, and there is a tree down across the second climb" — and closing a whole trail for one hazard is usually the wrong answer. So a maintenance item can be published as a public hazard.

Turn on Warn the public on the How bad is it? step of the field-app wizard, on the task's Edit screen in the field app, or on the item's form on the web. It is off by default, and it is only offered on an item that is on a trail, because the public pages list each hazard under its trail. It is not offered on an item whose safety risk is No risk either: a public warning about something your crew judged harmless says two things at once. Change the safety risk and the switch appears; set it back to No risk and the warning comes down.

The level comes from your two answers about the danger, so there is nothing else to fill in:

Safety risk	Can people get past?	The public sees
Serious risk	No	Danger
Serious risk	Yes	Warning
Minor risk	No	Warning
Minor risk	Yes	Caution

The priority does not change the level: it is also about when the crew gets to it, and that is your team's business. Only an item where the safety risk was never answered uses its priority instead — Critical shows as Danger, High as Warning, Medium as Caution and Low as Notice. Change either answer later and the public level changes with it.

Where it shows: an Active hazards list at the top of your public trail page, on each trail's and network's public page (a trail's page also marks each one on its map, as a warning sign in the level's color), in the trail-status widget you embed on other websites, in the report app on your organization's page and on the trail itself, and on your website — the Active hazards block lists them automatically, and the Trails block shows each one under its trail. Hazards show even if you have hidden trail status from the public: each one is something your team chose to publish.

What the public sees: the item's title, its level, whether people can still get past (Passable with care or Trail blocked), the trail, and the day it was reported. The description is never shown — it stays your crew's notes.

Your crew can see it too. While a hazard is showing, the field app marks the task with a Public hazard badge in its lists and a pill under the priority on the task itself, naming the level the public sees, such as Public · Caution.

It comes down on its own the moment the item is marked resolved. To take it down sooner, turn the switch off. A report from the public that is still waiting for review is never shown as a hazard, even if somebody turns the switch on; approve it first.

On a trail another organization has lent you, the switch is not offered: the public pages belong to the trail's owner.

Filtering, exporting, and the pending-review queue

The dashboard Maintenance list has a filter panel behind the Filters button:

• Status — chips at the top of the panel. Default view is "Unfinished only" (open + in_progress + pending_review), which counts pending-review items so you don't lose them. Switch to All or filter to a single status.
• Priority — Any + Critical/High/Medium/Low.
• Trail — filter to items on one specific trail.
• Issue type — same vocabulary as the create form.
• Network — filter to items on any trail in a given network.
• Crag / Climbing route — only visible when climbing is enabled.

Every combination is bookmarkable via URL query params — share the URL with a colleague and they see the same filter state.

Share in the header opens both exports, and both carry the filters you have set rather than the page you are on. PDF report is the one to hand somebody — your organization's name, logo and color at the top, the filters you used printed underneath, and the items in priority order. CSV spreadsheet is the same set as raw rows.

No bulk actions. There's no multi-select on the list today. Each item is handled individually.

Pending-review queue — the sidebar Maintenance entry shows a red badge whenever there are items awaiting moderation. In the field app it lives under its own Pending Reviews tab. Approve or reject each one; nothing gets to the public map until you do.

Sharing a task

Every task has a Share button in the Field App, offering two things:

• Link — opens the task in TrailsIQ. For your own crew, since it needs a login.
• Photo card — a story-shaped image, sized for social posts and messaging apps, that needs no login and no account to look at.

The photo card is built from the task itself: its status, its details, and a background you choose — one of the task's own photos, or the map. It is the answer to "show me what you've been doing" from a board member, a funder or a member who will never open a trail-management dashboard.

The obvious use is a before-and-after: card the reported hazard, card it again when it is resolved, and the pair tells the story of the work better than a status change in a list ever will.

A photo card is public once you send it. It is an image on somebody's phone; you cannot recall it. Check what is in the background photo — a license plate, a face, a house — before it leaves your hands. The map background is the safe default when you are unsure.

Planner lines have the same button with a longer menu — proposal link, photo card, PDF report and QR code. See Trail Planner.

Common gotchas

• There is no assignee field. Items go into a shared queue. Use Projects to group related items and assign the project instead.
• Public reports are always pending review. Even a report submitted by a logged-in owner via the public app lands as pending_review — the moderation gate is on the API, not the user. If you don't want a queue, use the field app or the web form.
• Rejecting a public report deletes it. There is no "hide from queue" — a reject removes the report, its photos, and every notification referring to it. Approve if you're unsure.
• A field worker can't reopen a resolved item. That's manager-only. If a resolved item comes back (e.g. tree re-fell in a storm), a field worker files a new item and cross-references the old one in the description.
• Trail Show pages don't have an "Add issue" button. The list on a trail Show page is read-only; use the Maintenance tab, the field app FAB, or (for climbing routes) the route's own Report issue link.
• Type is free-text, not a strict enum. The chip list is the recommended vocabulary but you can type anything — useful for one-off categories your org tracks. Custom types don't get their own icon on the map.

What's next

• Set up Projects to group related maintenance items — see the Projects and work planning article.
• Configure email preferences for your team so managers get notified about the categories they care about (pending-review, status changes, etc.).
• Turn on public reports in Settings if you're comfortable with the moderation workflow — it's the single biggest source of on-the-ground issue reports for most organizations.