Skip to main content

Running and tracking trails

A trail is the record of one run through a flow: which steps were visited, in what order, what was entered at each step, and what happened to the run along the way. When you start a flow, Floxar creates a trail for you and keeps it as a complete, reviewable history of that piece of work. This article covers starting a trail, moving through it, how your answers are saved, and what the finished record contains.

Starting a trail​

Starting a flow creates a new trail assigned to you, beginning at the flow's starting bit. A trail can be named so it is easy to find later in lists and search, and it carries a priority (low, medium, high, or critical) that can be adjusted on the trail itself.

You work one trail at a time: if you start or resume a trail while another of yours is active, the previous one is automatically paused. Nothing is lost — the paused trail keeps its place and can be resumed whenever you are ready.

Moving through the flow​

Floxar does not decide your path for you. At each step you read the bit's content, complete its interactive elements, and choose one of the navigation options shown in the bit to move on. Every bit you visit is recorded as a numbered step in your trail, and revisiting a bit — for example, in a retry loop — simply adds another step.

How your answers are captured and saved​

The interactive elements in a bit — checklists, dropdowns, radio buttons, date pickers, text areas, searchable fields, and tracked links and videos — capture your input as you work. Answers are saved automatically a few seconds after you enter them; you do not submit a form or save manually.

Answers belong to the step where you entered them. If you revisit the same bit later in the trail, that new visit records its own set of answers, so the history shows what was entered at each point in time. If a trail is not active or is not assigned to you, its elements are shown read-only.

Pausing, handing off, and queueing​

  • Pause a trail to set it aside; it keeps its assignee and its place, and you can resume it later.
  • Transfer a trail to hand it to a colleague. It lands on their worklist, and they start it themselves when ready — a handoff never interrupts what the recipient is doing. Every transfer is logged with who handed it off, who received it, when, and an optional reason.
  • Release to the queue to put a trail back in the shared pool with no assignee. Teammates with access can claim it onto their own worklist and then start it.

Completing a trail​

When the work is done, mark the trail completed; if it is stopped without finishing, mark it abandoned. Both states are final: the trail becomes read-only and serves as the permanent record of the run. If standard closing reasons have been configured for the flow, you pick one when closing and can add a free-text note.

A completed or abandoned trail can be reopened, but a reason is required and is recorded alongside the original closing event — the history is never rewritten.

What a trail records for later review​

Every trail keeps:

  • The full path — every bit visited, in order, with timestamps for each step.
  • Every answer — the values captured by each interactive element at each step.
  • Status history — every status change, with who made it, when, and why.
  • Handoff history — every transfer between people, including releases to and claims from the queue.
  • Time measures — how long the trail has been open, how much of that was active working time, and how long it sat paused or waiting after a handoff.

Interested parties are notified when a trail is completed or transferred. Because closed trails are preserved rather than deleted — even if the underlying content is later archived — they remain a reliable base for review, audit, and analytics.

Last reviewed: 2026-07-28