A Deep Dive into Postman Flows - Strengths and Weakness

** this post is updated on 28-07-2024

Postman has long been the go-to tool for API testing and development. Its user-friendly interface and robust feature set have made it a staple in many developer toolkits.
Recently, Postman introduced Flows, a new feature aimed at streamlining API workflows. It was released to the general public in March 2023.

I was truly excited about Postman Flow because it looked perfect for the task I was working on. However, I realised it wasn’t perfect after a few days working with it. As with any new features or tools, Postman flow comes with its pros and cons.

In this post, I will share my experiences with Postman flow. Please note this post is not a tutorial on how to use Postman flow. It is an overview of what it can and can’t do.

Postman Flows overview

Postman’s official site gives a good definition.

Postman Flows is a visual tool for building API-driven applications for the API-First world. It provides you with an infinite canvas to arrange and connect APIs.

Flows are an ideal solution for extracting data from an API-enabled product, transforming it to fit your needs, and viewing the results. You can also take data from one API-enabled product, process or make decisions based on that data, and then send it to another API-enabled product. This capability allows you to build real-time integrations between two API-enabled products.

Get started with flows

When we create a new flow, a blank canvas is shown with a start button. We can right-click to add an element from many “Blocks.”

Source: https://learning.postman.com/docs/postman-flows/tutorials/building-your-first-flow/

The blocks are divided into a few categories: action (i.e., Send request), decision/logic (i.e., If, Evaluate), and information (i.e., text, output).

The decision/logic blocks allow the flow control, such as if condition or looping. A Flows Query Language(FQL) is provided to parse and transform the data. FQL supports some basic functions like $count or $each. They can be used with the Evaluate block to manipulate the JSON data.

Source: https://learning.postman.com/docs/postman-flows/tutorials/building-your-first-flow/

Like other entities in Postman, the flow resides within the Postman workspace. You can share or fork the flow within the team workspace or move it to another one.

Overall, it is a powerful and good-looking tool.

Let’s dive into the good parts first.

Good Parts

A tool with Visualization

It is a nice looking visual tool, and the running animation looks great. The animation enhances the running experience, and it makes the flow easier to understand.

Source: https://learning.postman.com/docs/postman-flows/gs/flows-overview/

If you turn on the dark theme, it looks even better.

Low-code /No-code

Prior to Postman Flow, we would need to use the collection runner to chain a few requests. The collection runner would execute the requests by order of requests in the collection or write a script with setNextRequest method to create a manual workflow.

With Postman flow, we only need to drag-and-drop, no code necessary. This is great for non-technical users.

The ability to select from the sample response data.

The Select block is used to select a value from the output of the upstream block (i.e., the response body of the previous request).

It works well with JSON response data, as well as HTML(although it isn’t documented). After you run the flow once, the response data will be saved as an example, and you can choose from a drop-down with the example data.

Source: https://learning.postman.com/docs/postman-flows/tutorials/using-response-data-in-a-request/

Re-use Existing Requests

If you already have existing Postman collections/requests, they can be easily dropped into the flow canvas and chained into a workflow. This is a huge advantage for my project because we have accumulated many Postman requests over the years, most of which are standalone.

Using the Postman Flow, we can connect them with minor modifications. It provides more test coverage and increases the visibility for business users.

Compared with the old collection approach, flow can share the existing request in the collection. In other words, you don’t need to duplicate requests to get them into the flow. That makes the flow building much cleaner and more re-usable.

Bad Parts

Postman offers a free plan which allows you to run basic API tests and other features, including flow. But keep in mind that Postman isn’t an open-source tool. The free features may be changed or limited at any time. Recently, a new limitation was added to restrict the number of runs for free and “professional” paid account usage, which many developers felt unjustifiable . So, it is something to consider when investing effort into building API tests with Postman flow.

Lack of Export and limits on the free plan

Postman allows you to export requests, collections, and environments to JSON files. These exported files are very handy, as they can be shared between the team and/or stored in the version controller system.

However, the flow cannot be exported. This feature isn’t being provided, though many developers have asked for it in the Postman forum. Instead, the capability to share the flow with Postman team workspace is provided. This means only team members can access or fork a flow.

Lacking the export feature also means the flow can only be stored in Postman’s workspace.

To make things worse, the free plan has a limit of 3 members in a team workspace. Although the flow feature is available to a free plan, those limitations make it almost non-usable in a team.

From a business perspective, it is understandable that the free plan is limited. However, I found it hard to justify that the export feature doesn’t exist for even paid account users.

Limitation of Environment Variables

Although we can re-use the existing requests in a flow, there is a hidden limitation: you can’t modify an environment variable or collection variable inside the flow.

It is very common to have these scripts embedded in a Postman request:

pm.environment.set(“variable_key”, “variable_value”);
pm.collectionVariables.set(“variable_key”, “variable_value”);

But if you use one of these requests to build your flow, the script above will throw an error. It is a design decision from the Postman team.

Below are some extracts from the Postman team’s response.

“_Environment works in a read-only mode, updates to the environment from scripts are not respected._”

“_We encourage using the connection to pipe data from one block to another, rather than using Globals/Environments, etc._”

I am disappointed with this decision. It breaks many of my existing request scripts. Many developers are in the same situation.

Limiation of If block

There is an important logic block in flow: if. It is a logical gate that allows you to decide the flow path based on the input.

Source: https://www.postman.com/postman/workspace/flows-snippets/flow/63bcba94f3155f2e86b54eb0

As in any programming language, if is the most essential building block. The issue of if block in Post flow is that it only supports one condition.

When we have more than one condition, the workaround is to chain multiple if blocks together. In a real-world project, multiple conditions are extremely common. Chaining multiple if blocks for one line of code is so cumbersome!

These are the main issues I encountered in my few days experience with Postman flow.

Conclusion

Postman Flow offers a promising path for simplifying API testing, but there are currently some limitations to consider:

• Limited Export Options: Currently, Flow lacks a robust export feature. This could make it challenging to integrate workflows into existing CI/CD pipelines or share them with team members for broader adoption.
• Single-Condition “If” Blocks: The current iteration of Flow seems to only support single-condition “if” statements. This might limit the complexity of logic you can implement within workflows, hindering use cases requiring more advanced branching scenarios.
  Additional Considerations

Beyond the specific feature limitations, there are some broader concerns to address regarding Postman’s product philosophy:

While Postman offers a free plan, certain features crucial for efficient workflows might be restricted. I have reservations about Postman’s product philosophy, particularly concerning to the way of pressuring users to a paid account , rather than providing value added services that naturally encourage users to upgrade.

Overall, Postman Flow holds significant promise for streamlining API testing. However, addressing these limitations and exploring a user-driven product philosophy can unlock its full potential and solidify its position as a game-changer in the API development landscape.