Describing your flows

A flow definition is a short description of a journey your users take: the steps, what "done" means, and how much it matters. Drift and the release report both use it. Without one, both still run — they just describe your product in URLs instead of your own words.

What a definition changes

In Drift: when a pull request regresses a flow, the step it lands on is named ("Payment details", not /checkout/step-2). Small drops in a flow you marked critical outrank big drops in one you marked minor. Behaviour you said is normal — a slow third step, a guest-versus-signed-in branch — is removed from the state before it's judged, so it stops showing up as noise.

In the report: findings are grouped by flow and ordered by how much the flow matters, headline completion is measured against the goal you wrote, and each finding says whether it came from a defined flow or a bare one.

Describing a flow

Go to Flows and write two or three sentences the way you'd explain the journey to a new teammate:

Checkout starts at the cart, goes through shipping and payment, and is done when they see the order confirmation. It's our most important flow.

The extracted structure — steps, goal, criticality — appears beside the text as you type so you can see it was understood. Save it. It sits in Pending until there's enough data to check it against.

Grounding and confirming

Once your workspace has about 30 sessions from the last two weeks, each described step is matched to real pages and events. The flow moves to Ready to confirm and you get a notification.

On the confirm screen every step shows the page or event it matched, how many sessions reached it, and the drop-off from the step before. A step that couldn't be matched is highlighted with the closest candidates; pick one, or type a URL pattern or event name yourself. A flow can't be confirmed while any step is unresolved — that's deliberate, because an unresolved step would make Drift blind to it.

Confirming makes the flow Active. Only active flows enrich Drift or the report.

What inference adds

Once a day UXSense looks at recent sessions for two things:

• Flows you didn't describe. Busy or high-drop-off paths no definition covers appear at the top of the Flows list as Suggested. Describe them, confirm them as-is, or archive them.
• Places your description is wrong. If a quarter or more of the people entering a flow skip a step, take a branch you didn't mention, or finish somewhere else, the flow shows a side-by-side of how you described it against how users actually move, with a proposed update. Nothing is changed until you accept it.

An active definition is never rewritten automatically.

Editing

Every edit creates a new version. Each Drift check and each report records the version it used, so history stays comparable when you change a flow. To record a tolerance, just say it: "step 3 is always slow, that's normal."

Skipping

You can skip describing flows during setup. Drift and reports run in bare mode, and a "Describe this flow" prompt appears in place the first time a finding lands on a journey you haven't defined.