Trail conditions: telling the public what's open

The question you get asked most isn't "how many kilometres do you have?", it's "is it open today?".

Trail conditions answer that one. You build a report listing your trails with their state, you keep it current in seconds from the field, and you publish it on your website. Users see the same thing your crew sees, at the same time.

Three states, no more:

That economy is deliberate. A seven-shade scale never gets kept up to date; three states do.

Where: left navigation bar, under Administration → Trail conditions.

One report per audience, not per network

A condition report is an ordered list of trails, attached to an activity. You can have several per activity, and that's often the right call: a public one for the website, a more detailed internal one for the crew, a seasonal one.

Each report belongs to exactly one activity. On entering the section you pick the activity first, then the report — unless you only have one, in which case Sentinel takes you straight there.

Building the report

Inside, you build the list from two bricks: trails and folders to group them.

A few mechanics worth knowing:

Folders are one level deep. A folder holds trails, never another folder. That's a deliberate constraint: a public report three levels deep isn't readable.

The order is yours. Drag the rows, or use Sort to arrange them all at once by difficulty and name. What you see here is exactly what a visitor will see.

Nothing is saved until you hit Save. Additions, removals, condition changes, reordering: it all accumulates locally and goes out in a single submission. If you leave the page with pending changes, the app holds you back.

Applying a condition to a folder is the highest-value gesture in the section: close "North sector" entirely after rain, then reopen the two trails that dried out.

Removing a trail from the report doesn't delete the trail. It leaves the public list, that's all.

The same trail in several reports

This is where it gets interesting. If a trail appears in two reports, changing its condition in one propagates to the other on save. You don't have to maintain two lists in parallel.

The same holds when adding: a trail already present elsewhere arrives carrying the condition it already has, not a default "Open".

The guard on "Open"

If you set a trail back to Open while it still carries in-progress tasks, Sentinel stops you and tells you how many. You get two buttons: Set Open anyway, or Under construction.

It isn't a block, it's a reminder — nine times out of ten, someone forgot a crew was still out there.

Automatic updating

Each report has a setting, in the ⚙ menu of its header: automatic condition updating. It is on by default, and here's precisely what it does.

When a task attached to a trail moves to In progress:

• that trail goes to Under construction in every report where the automation is on;
• unless it is already Closed — a manual closure is never overwritten.

When that task leaves In progress:

• Sentinel checks whether any other in-progress tasks remain on that trail;
• if none remain, the trail goes back to Open.

In other words, your report keeps itself current during the work, provided the crew moves its tasks to In progress when they start. That's the real reason to do it.

When to turn it off: when you want the public report to move only by human decision. The setting is per report — you can perfectly well run an automatic internal report and a manual public one.

From the field

On mobile, conditions are one of the view switcher's views, alongside the map and the checklists. You open it, you change a state, done.

The place band stays on top — it's the same shell as the map. There's no filter row and no filter button on this view though: it doesn't need them.

Two differences from the web, both intentional:

It's immediate. No Save button: you pick the state, it goes. In the field, with gloves on, a two-step flow doesn't survive.

You don't build the report from mobile. Adding trails, creating folders, reordering: that's desk work. Mobile is for updating, not for building.

You'll also see a prompt appear when you start a task on a trail tracked by a report: "Do you want to set its condition to Under construction?". It's the manual counterpart of automatic updating.

Publishing on your website

This is the part your users see. The Widget button, on a report's row, opens its embed page.

The normal method: two tags

The script in the <head>, once per page even if you display several reports. Then a <div> tag exactly where the widget should render. That's it: no account, no API key to protect, no code to write.

The data-lang attribute fixes the widget's language for your visitors, independently of yours.

If your platform blocks scripts

SharePoint, some intranets and sites with a strict security policy refuse external scripts. For those, the page offers an iframe — same content, no third-party script to load.

And if the iframe is blocked too, the address inside its src attribute is a full page: it opens as-is in a browser. You can link to it from a menu or send it by email.

What a visitor sees

The widget draws itself with the host site's font, not Sentinel's — it's built to blend in, not to stand out. A Customization tab lets you set the width, corner radius, shadow, header and section colours, and decide whether to show the header, the date, and a map of the tracks beside the list.

Three things worth knowing:

The widget refreshes on its own, roughly every minute, without the visitor reloading the page. A trail you close from the field shows as closed on their screen shortly after.

The address carries a token, not your place's identifier. That token grants access to this report and nothing else: not your tasks, not your members, not your other reports.

Turning the switch off cuts access, immediately and everywhere the widget is installed. That's the gesture to know if a report gets published by mistake.

Who can do what

Conditions fall under the Trail conditions right in the place settings.

• With read: see the reports and the states, change nothing. On mobile the badges stop responding to touch.
• With read and write: create reports, build them, change conditions, enable the widget and customize it.

The right is the same for everything: there's no middle level that would allow changing a condition without being able to publish the widget. If you want field crews updating states, they need write — grant it, knowing they can also touch the widget.

Three pieces of advice

Keep the public report short. The visitor wants to know whether their usual loop is open, not read your 60 segments. Group by sector and only expose what they recognize.

Leave automatic updating on for the report your crew feeds, and get them into the habit of moving tasks to In progress. You get a current report with no extra gesture at all.

Test the embed before handing it to your webmaster. Open the .../embed address in a tab: if the page renders, the token is good and any remaining problem is on the host platform's side, not Sentinel's.