Your first flow

Chapter 00 got you an account and a workspace. This one gets you something you made: a two-card flow, a scenario that walks it, and a recorded run.

You will build it twice — once by hand, once by asking an AI assistant. Both routes end at the same project, because the assistant and the web app are two doors into the same data.

After this chapter you can author a flow of your own, pin a scenario through it, record a run, and drive all three by conversation over MCP.

About fifteen minutes by hand, five more for the MCP track if you already have an assistant to hand.

What you are building

A door with a keypad. Two cards:

• Idle — the keypad at rest. One action: Start.
• Enter PIN — one action, Submit, with two results: Correct opens the door, Wrong refuses it.

Two ends: Door opens and Refused. That is the smallest flow with a real decision in it, which makes it the smallest flow worth a scenario.

Track A — by hand

1. Create a project

1. Open your workspace. If you do not have one yet, click ✦ Use this browser (no setup) on the workspace screen — nothing to configure, and you can move the project to Drive or a folder later.
2. Type Locker in New project name and click Create.
3. The project opens on No flows yet — a project holds flows, and you need one before there is a canvas to draw on. Type Door in the New flow box at the bottom of the left sidebar and click +.

The flow opens on an empty canvas.

2. Drop two cards

Cards come from the stamp: press C, or click the ＋ Card button on the canvas toolbar. Its ▾ chooses what the stamp drops — a card, an end, or a note. Leave it on card.

1. With the stamp armed, click empty canvas twice. Two cards appear. The stamp stays armed until you leave it, so a run of cards costs a run of clicks.
2. Press Esc to put the stamp away.

The first card is the entry — it carries the ENTRY marker.

3. Fill them in

Select a card and the Inspector opens on the right.

1. Select the entry card. Set its Title to Idle.

2. Under Branches, type Start into the action field and click +. Leave the result field blank — this choice has only one outcome.

3. Select the second card. Set its Title to Enter PIN.

4. Under Inputs, click + add, name the field PIN, set its value to 4242, and leave the type on text.

5. Under Branches, type Submit and click +. Set the new branch's result field to Correct. Type Submit again and click + — a second branch with the same action is fine as long as the result differs — then set its result to Wrong.

   One button, two things that can come back. During a run these appear grouped under a single Submit heading and the tester picks the result they actually got.

4. Connect them

Branches leave a card as labelled outlets.

1. Drag from Idle's Start outlet onto the Enter PIN card.
2. Set the stamp's ▾ to End, then click two empty spots on the canvas to drop two ends. An end has no title — its name is its Outcome field — so open each in the Inspector and set one to Door opens and the other to Refused. Press Esc to put the stamp away.
3. Press X for the connect tool: click a card's outlet, then click the inport handle of the card it leads to. Click Enter PIN's Submit / Correct outlet, then Door opens's inport. Do the same from Submit / Wrong to Refused.

On a trackpad, dragging a handle is fiddly — the connect tool is the easier route either way.

You now have a flow with two paths through it.

5. Pin a scenario

A scenario freezes one path so you can run it the same way every time.

1. In the editor bar, open the scenario dropdown and pick ＋ New scenario…. Name it Correct PIN.
2. The flow locks. That is deliberate — while you pin a path, an accidental drag would move a card for every scenario at once. Press H to edit the flow mid-scenario, then lock again to carry on.
3. The card the path has reached shows its actions. Click Start on Idle, then Submit / Correct on Enter PIN. Each click takes that branch and the walk moves on; cards past it stay dim until the path arrives.
4. The bar over the canvas counts your choices — 2 choices pinned · unsaved. ↶ Back drops the last one if you change your mind.
5. Click Save.
6. With the scenario still selected, use the Inspector's Expected outcome field to set it to Door opens.

Choices are a draft until you press Save; Discard puts the scenario back to its last saved path.

6. Run it

1. Click the Player tab.
2. Pick Correct PIN in the scenario dropdown.
3. Click Start run.
4. Because the scenario pins a path, each card shows one Next — (branch) button instead of separate branch buttons — but it stays disabled with Mark Pass or Fail to continue until you mark the step. On Idle, click ✓ Pass, then Next — Start.
5. On Enter PIN, click ✓ Pass, then Next — Submit / Correct.
6. The walk ends on Door opens.

You have authored a flow, pinned a scenario through it, and recorded a pass.

When a step misbehaves, File bug sits in the player toolbar during a run and records the steps you walked. Chapter 04 covers bugs properly.

Track B — by asking an assistant

Everything above is reachable over MCP, so an assistant can do it by conversation. The result is the same project, live in the same UI.

1. Create a token

1. Open the profile menu, top-right, and click MCP access tokens.
2. Give the token a name — Create stays disabled until you do — then create it and copy it. It is shown once.

A token is how an assistant proves it is you. It carries your access and nothing more.

2. Point your assistant at Flowline

Add Flowline to your MCP client as a remote server:

• URL — https://<your-flowline-host>/mcp
• Header — Authorization: Bearer <your token>

The spelling differs per client; chapter 06 has the configuration for Claude Desktop, Cursor, and Copilot CLI, and covers the two other ways to connect — a local process against your own instance, or the flowline-mcp helper against a folder on your computer.

3. Build the same flow by asking

Point the assistant at the right workspace first, then work in plain language:

"List my workspaces and select the personal one."

"Create a project called Locker."

"In that project, build a flow: an idle screen with a Start branch, then a PIN screen whose Submit action has Correct and Wrong results, ending in Door opens or Refused."

"Add a scenario called Correct PIN, set its PIN to 4242, and expect it to reach Door opens."

"Put that scenario in a suite called Smoke."

"Start a cycle of that suite on Staging against build 1.0.0, mark the scenario passed, and finish the cycle."

Behind those asks the assistant calls list_workspaces and select_workspace, then create_project, create_flow, create_scenario, create_suite, set_suite_scenarios, start_suite_run, set_suite_result and finish_suite_run (how a write saves).

A result is recorded against a suite cycle, so an assistant reaches for a suite even when there is only one scenario to run — that is what puts the outcome in the pass-rate dashboard and the cycle history. A cycle needs an environment, a build version and a test date, which is why the ask names all three.

Keep the web app open while it works — the open project merges each change as the assistant saves it, or within 15 seconds (08).

Selecting a workspace matters. On a hosted connection each session picks its own, so a session that skips select_workspace writes somewhere you did not mean.

Both doors, one project

Both tracks build the same flow and the same scenario in the same project, and that is the point. They differ only in how the result gets recorded: by hand you walk the scenario in the Player, and an assistant records it against a suite cycle.

So the two hand off to each other. An assistant can draft a flow from a spec in seconds and you open it, read it, and fix what it got wrong — or you author by hand and give the regression pass to the assistant.

Where to go next