Skip to main content
When a worker finishes, the task moves to In Review and a notification appears. The review workflow gives you full control — read the report, inspect the diff, optionally run the exact version, and then approve or request changes. Code is never delivered without your explicit approval, and earlier results remain available even if a new attempt produces a newer one.

​
The Review Notification

When a worker completes its attempt, the task moves from In Progress to In Review on the board. A notification appears in the Needs You panel to draw your attention to it. Open the task feed to see the full result — the report, the verification output, and any questions or observations recorded during the run.

​
Read the Result

The task feed shows everything the worker produced:
  • Outcome report — the worker’s written summary of what it did and what it found
  • Verification output — the results of any checks you configured (for example, make test)
  • Testing observations — any notes recorded during the attempt
Read these carefully before deciding whether to approve, request changes, or try the result manually.

​
Inspect the Diff

To see exactly what code the worker changed, click Inspect in the browser, or use the CLI:
The diff view shows every file the worker added, modified, or removed. Inspection is informational — viewing the diff does not approve the result or begin delivery. You can inspect freely without committing to anything.

​
Try the Result

If you want to test the code before approving it, use Try Result in the browser. This launches an independent copy of that exact version of the code in its own environment, so you can explore and test manually without affecting your project files or the original worker output. Record what you find as testing observations in the task feed — this builds a useful history for the task. Recording a test result does not approve the code. You still need to explicitly approve and integrate when you’re satisfied.

​
Request Changes

If the result isn’t right — the implementation is incorrect, the checks fail, or it misses the intent — click Request Changes in the browser and leave notes explaining what needs to be different. The coordinator sees these notes and can refine the task definition, add clarifying decisions, or create a follow-up task. Requesting changes returns the task to a state where a new attempt can be prepared and run.

​
Approve and Integrate

When the result is correct and ready to ship, click Approve and Integrate in the browser (or use flowfield task results review with the appropriate flags — see flowfield task results review --help). Flowfield then:
  1. Validates the candidate commit
  2. Delivers the code to your configured project branch
  3. Marks the task Done
Once a task is Done, the agreed outcome is complete and the code is in your repository.

​
What If Delivery Is Blocked?

If local edits in your project checkout prevent Flowfield from delivering the approved code, approval is retained — it isn’t lost. The result will explain what’s blocking delivery and what action to take next. Once you’ve resolved the blocker (for example, by committing or stashing your local changes), retry delivery:
Run flowfield task results retry-delivery with the appropriate result ID once the blocker is cleared. The previously approved candidate will be delivered without needing a new review.

​
CLI Review

You can list and inspect results entirely from the CLI:
For approval and request-changes operations from the CLI, see:
Exact-candidate approval from the CLI uses the same record as browser approval — you won’t see a duplicate confirmation in the browser.
Earlier results remain inspectable even after a new worker attempt produces a newer result. You always choose which result to approve — Flowfield never automatically promotes a newer attempt over an older one.