What makes a good flow
A flow is a sequence of connected bits that leads someone to a defined outcome — a reusable template for a piece of work. Each time a person runs it, Floxar records their journey as a trail. A good flow is a repeatable, practical path: clear about when to start it, what "done" looks like, and every decision in between, yet simple enough to follow under pressure and to update as the process changes.
Put decisions inside bits, not in the connections
Floxar does not execute a flow for you. Whoever runs it — a person or an agent — reads each bit, decides what applies, and picks one of the outgoing connections. Connections themselves carry no conditions or logic; they are only paths. Every decision therefore has to be spelled out in the bit where it happens: the question being asked, the criteria for each answer, and which path matches which answer. If a reader has to guess which way to go, that is not a style problem — it is how work goes wrong.
Give the flow one clear trigger
From the title and description alone, a reader should be able to tell when this flow should be started and what situation it handles. A flow answers one process need, not several. If one flow tries to cover multiple unrelated triggers, split it into separate flows — each with a name that says what it is for.
Make "done" unambiguous
A good flow has an explicit end: one or more final steps that represent the goal being achieved. Someone running the flow should always know whether the work is complete. A step with no way forward should exist only because the work is finished there — never by accident.
Sequence steps the way the work happens
Order bits the way the work is actually done. The starting bit should lead onward, every bit should be reachable from the start, and there should be no stranded steps that nothing connects to. A single straight line can still hide problems: if the reader has to make uncaptured judgment calls between steps, those are missing decision points, not smooth sequence.
Make handoffs explicit
Wherever execution passes between people, teams, or from a person to an agent, make the handoff a deliberate, named step: who takes over, and what condition must be met to proceed. Mentioning another team in passing does not count. For example, if legal must sign off before publishing, add a step that routes the work to legal — do not assume the reader knows to involve them.
Branch only on real decisions
A branch should represent a genuine choice, with the decision criteria stated in the bit where the choice is made — one decision per branching point. If a bit asks more than one question, split it. Avoid fake branches (multiple paths that are not a real choice, or a "decision" whose criteria are never stated). And where a step needs data captured, include the right interactive element; where it produces something, say what and where — the reader should never guess what to record.
Make repetition explicit
If the process retries, polls, or loops back for rework, represent that deliberately. Either connect back to the step being repeated — a step can even connect back to itself for retry patterns — or, where a connection cannot express it, state the repeat-until, retry, or escalation condition in the bit itself. Never flatten a repeating process into a one-way path and leave the reader to infer when to go back.
Keep the right altitude
A flow is a template, not an essay. Each bit should be one focused unit of work: do not cram a whole workflow into one enormous bit, and do not fragment trivial steps into bits of their own. Structure at this altitude keeps the flow adaptable — when the process changes, the fix should be a localized edit to one bit or one branch, not a redesign.
Most of these criteria are craft: falling short makes a flow weaker, not invalid. The exceptions are unstated branch criteria and missing required inputs — those can send someone down the wrong path while everything looks fine, so fix them first.
Last reviewed: 2026-09-23