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 the public report app; 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, Other (plus climbing-specific types if your organization has climbing enabled). Picking Broken structure asks you which structure on step 4.
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.
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. Details — Title (optional), Priority (defaults to Medium), Project link (optional), Structure link (only when you picked Broken structure), Description ("What's going on?").

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

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 the public report app 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 — free-text or picker (placeholder: "downed_tree, erosion, signage…"). Vocabulary: blowdown, water, erosion, drainage, signage, surface, overgrowth, broken_structure, machine_work, adaptive_improvements, trash, hazard, other — plus climbing-specific types if enabled. Picking broken_structure reveals the Linked structure field.
• 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).

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 and the slide-out detail panel have inline status buttons for one-click In progress / Resolved transitions. Open is manager-only (a field worker can't reopen a resolved item — that requires a manager).

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.

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

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.

Two export buttons sit in the header, and both carry the filters you have set rather than the page you are on. Export PDF 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 is the same set as raw rows, for a spreadsheet.

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 is a hard delete. There's no soft-delete or "hide from queue"; a reject removes the row, its photos, and every notification referencing 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.