Postman Flows — Building Visual API Workflows

Up to now every multi-step workflow you've built in Postman has lived in scripts — pm.collectionVariables.set in one Tests tab, {{token}} referenced in the next request, ordered top-to-bottom in a folder. Postman Flows is the visual alternative: a canvas where you drag blocks for requests, transformations, conditions, and loops, and connect them with wires. It's no-code orchestration sitting on top of the same collections you already have. This lesson covers when Flows earn their keep, the block types you'll use most, and the trade-offs versus the scripted approach.

When a visual workflow makes sense

Scripted chaining (Chapter 4 Lesson 1) handles ~90% of test workflows. Reach for Flows when:

The workflow has branching — "if user is admin, do A; otherwise do B."
The workflow involves looping — "for each item in this array, fire a request."
You want to demo an API workflow to non-engineers (a product manager, a stakeholder, a sales engineer). A picture beats five Tests tabs of JavaScript.
You're prototyping an integration before writing real code. Drag-and-drop is fast.
You're combining data from multiple APIs in non-trivial ways.

When Flows is wrong:

You're writing tests that need to run in CI. Newman doesn't run Flows (yet).
The workflow is genuinely linear A → B → C. A folder of ordered requests is simpler.
You need to do anything Flows blocks don't natively support — drop into scripts and stay there.

Creating a flow

Click New (top-left) → Flow, or open the Flows tab in the sidebar and click +.
Name the flow. The canvas opens — empty grid, block library on the left.
Drag a Send Request block onto the canvas. A picker opens — choose any saved request from any collection in the workspace.
Click Run at the top of the canvas to fire that one request.
Drag more blocks. Connect them by dragging from one block's output port (right side) to another's input port (left side). Wires carry data.

Each block runs when its inputs are ready. The canvas is reactive: when you change anything (or click Run), Postman traces the wires and executes the connected blocks in order.

The blocks you'll use most

Postman Flows canvas

– Pick a saved request
– Variables resolve from active env
– Output: full response object

– Pull a value out by JSON path
– e.g. response.body.token
– Output: just that value

– Run a JS expression on inputs
– Transform, format, derive
– Output: the expression's result

– Branch on a boolean
– True path / False path
– Lets you build if/else trees visually

Iterate over an array –
Fire a request per item –
Aggregate results downstream –

Render a value on the canvas –
Tables, JSON viewers, KPI cards –
How you 'see' the result –

The block list grows over time as Postman ships new ones, but those six are the daily vocabulary. The pattern is always the same: request → extract → transform → branch/loop → display.

A worked example — admin dashboard

Imagine you want to display every admin user from your /users endpoint. As a flow:

Send Request → POST /login — gets the auth token.
Select on the response: body.token.
Send Request → GET /users — uses the extracted token in its Authorization header (Flows wires variables in for you).
Select on the response: body — the array of users.
For Each over the array: each user becomes the input of the next stage.
Condition — user.role === "admin". True wires through; false wires nowhere.
Output → Display as table — the filtered admin users render as a table on the canvas.

That's a 7-block flow, no scripts. The Tests-tab equivalent is roughly 15 lines of JavaScript and a forEach loop. Both work; the visual one is easier to demo and explain.

Flows vs the scripted approach

A direct comparison on the chaining example from Chapter 4:

Concern	Scripted (Tests tab)	Postman Flows
Linear chain (A→B→C)	One request per step, `pm.collectionVariables.set` between them. Simple, fast.	Three Send Request blocks wired in a line. Slightly more visual ceremony for the same outcome.
Branching (`if X else Y`)	`if/else` JS in a Tests script that calls `postman.setNextRequest`. Works but is fiddly to read.	One Condition block with two output wires. Reads like a flowchart.
Looping over arrays	`forEach` in a Tests script with `pm.sendRequest` per item. Async callbacks get hairy.	One For Each block. Postman handles concurrency.
Running in CI	`newman run` — works perfectly.	Not yet supported by Newman.
Sharing with non-engineers	"Open this Tests tab and read the JS" — bad.	"Open this canvas" — they can read the diagram.
Performance / load testing	Limited; use a real load tool.	Not a load tool either.

Pick by use case. A test suite that runs in CI: stick with scripts. An exploratory or demo workflow: Flows is faster.

Variables and environments in Flows

Flows reads from your active environment the same way regular requests do — {{baseUrl}} and {{authToken}} resolve. The dropdown for picking the environment lives at the top of the canvas.

You can also pass values directly along wires without using variables — wire the output of one Send Request block into the headers of another, and Postman drops the value in. Variables are still useful for things many blocks need; wires handle the per-flow plumbing.

Outputs and observation

The Output block (also called "Display") is what makes Flows demo-friendly. Drop one at the end of your flow; pipe a value in. The canvas now shows the result inline:

Table — rows of objects, sortable.
JSON — raw inspector with collapse/expand.
KPI — a single number in big type (e.g. "12 admins").
Status — green/red dot for boolean.

Click Run and the outputs update live. This is the "demo to a stakeholder" mode — open the flow on a screen-share, click Run, watch the outputs populate.

Limitations to know

Flows is younger than collections and scripts; the limits are real:

No Newman support yet. You can't run a Flow in CI today. If you need automation, build the same workflow in scripts.
Smaller block library than custom code. Anything not in the block list requires an Evaluate block with JS — at which point the script is doing the work.
Sharing requires the Postman GUI. A Flow is meaningless outside Postman. A script-based collection runs anywhere Newman runs.
Versioning is awkward. Flows don't diff cleanly in Git like collections do. Less robust for team workflows that depend on PR review.
Performance ceiling. Flows isn't a load test tool. It's for orchestration, not throughput.

For most QA workflows in 2026, scripts + Newman is still the production-grade path. Flows is the exploration and demo layer on top.

A few good use cases

Real things teams use Flows for today:

API health-check dashboards — five Send Request blocks against /health endpoints, each piped to a status Output. One canvas, instant answer to "is everything up?"
Onboarding demos — show a new tester the shape of an API workflow visually before they read any code.
Data shape exploration — call a few related endpoints, drop their outputs onto the canvas as JSON viewers, eyeball the shape before writing tests.
Cross-API joins — combine data from two APIs in a way that would be ugly in a single Tests script.

What teams don't use Flows for: anything that runs without a human, or anything that needs to live in version control.

⚠️ Common mistakes

Building a Flow when a folder of ordered requests would do. Flows adds visual ceremony you don't need for a linear A→B→C workflow. Reach for it only when branching, looping, or visual sharing is the actual goal.
Expecting Flows to run in CI. It doesn't (yet). If your workflow needs to be automated, design it as a scripted collection so Newman can run it.
Using Flows as a substitute for tests. A Flow that "works" on the canvas isn't the same as a passing test suite. Tests live in pm.test() blocks; Flows orchestrates requests.

🎯 Practice task

Build a working flow. 30 minutes.

Create a flow. New → Flow. Name it JSONPlaceholder Health Check.
Add a Send Request block. Pick GET All Users from your JSONPlaceholder API Tests collection. Click Run on the canvas. The block's output should show the response object.
Add a Select block. Wire it to the request's output. Set the path to body.length (the number of users in the array). Add an Output block downstream — choose KPI display. Click Run. The number 10 should appear.
Add a Send Request → GET User by ID. Wire it after the Users block — but first, add a Select on the users response that pulls body[0].id. Wire that into the second request's URL via a variable. Click Run. The second request should fire with whatever ID came out of the first.
Branch. Add a Condition block with the expression output.body.email.includes("@biz"). Wire the Get User response into it. True path → Output "biz user!"; False path → Output "not a biz user". Click Run. JSONPlaceholder's user 1 has email Sincere@april.biz, so the True branch fires.
Loop. Add a For Each block on the users array. For each user, wire to a smaller Send Request → GET User Posts (/users/:id/posts). Pipe the post counts into a Table output. Click Run. The table renders a row per user with how many posts they have.
Stretch: point the flow at multiple /health style endpoints (or use multiple JSONPlaceholder paths as stand-ins) and build a status dashboard with five Status outputs. Click Run — the canvas now reads as a one-glance "is this API up?" page.

You've built your first Postman Flow. The next lesson covers the other shareable artefact Postman builds out of your collections: auto-generated, browsable API documentation.