Based on your previous feedback on the topics within the postman-flows tag - we would LOVE to hear your feedback about the current Postman Flows functionality
It will really help us to shape the overall feature and continue to offer a wonderful experience for so many Postman users.
As an analyst, I would like to make the following suggestion. We are working to run our test automation processes in flows. I think it would be a very useful feature to run the blocks in the area we select instead of pressing a single run button and running all the blocks. I would be very grateful if you could evaluate this.
I absolutely love Flows, and I am starting to use it everywhere possible, especially for CI/CD in DevOps. Below are some of my suggestions and bug reports.
Feature Suggestions
Where Used (Under Flow Details)
It would be helpful to see at a glance how many places a flow is used as a flow module in other flows.
When creating a new snapshot, it would be great to have an option to automatically update the snapshot version in all places where the module is currently used. This would eliminate the need to manually update versions in multiple flows.
Select Option for Flow Module Inputs
Similar to the “Send Request” component, it would be convenient to have a direct “Select” option for module inputs. Currently, a separate select component is required, which adds unnecessary complexity.
Support for Status Polling in Flows
Many API endpoints return statuses like “processing,” requiring repeated queries until the status changes. Currently, it is not possible to create such a flow in Postman because flows cannot trigger themselves.
While it is possible to insert a delay or loop before proceeding, this approach is unreliable since processing times can vary greatly.
Suggested Solution
Introduce a back-trigger component that allows a flow to send a signal to itself.
Alternatively, enable a “Send Request” component to be triggered by multiple input signals. With this functionality, users could connect an “if” block to check the status and trigger additional steps when conditions are met.
Bugs
Group Resizing Issue
When selecting a version/snapshot for a flow module contained within a group, the group is sometimes incorrectly resized.
Here’s two very quick mini feature suggestions for you:
When under the main settings for a Request, when editing Query or Body parameters, it would be good to be able have a “create variable” context menu item that creates a {{var}} for you in the 2nd value column quickly. I find myself copying the key name of the parameter and then pasting it in that 2nd value column wrapped in {{ }}}.
This one would be very useful. The ability to hide/show specific rows of variables in a Flow Request block so save space. Seems one can currently only choose to hide or show them all. One could also have a feature for hiding any variables that don’t currently have connected Ports.
We have thought about this problem quiet a bit and will hopefully have some improvements here in the coming months.
One question: What motivates the desire to only run a portion of your flow? Is it while you are building it easier to just test the new part of the flow?
First of all, thank you for caring about feedback.
If I give a very simple example, I think it would be healthier to run the test scenarios that I expect to succeed and fail separately. You may think that we can run them in separate streams, but seeing this situation in a single canvas makes it easier for both the developer and the analysis & test team.
We may also have integration processes with other companies, which many large companies do. Here, running the integrations separately in a single window will provide great convenience.
I frequently use flow modules, but debugging becomes challenging when one module calls another module, which then calls another, and so on. When something fails, it can be difficult to trace the issue.
Here are a couple of suggestions to improve debugging:
1. “Create as Scenario” Button in the Flow Module Components Toolbar
In the example below, a call to a flow module fails. It would be incredibly helpful to have an option to:
Take the current input values with which the module was called.
Automatically create a scenario for the module.
Open the module and provide a prompt to run it with the created scenario.
This feature would significantly streamline debugging and make it easier to replicate issues.
2. “Pause on This Block” for Flow Modules
Currently, the “Pause on this block” functionality only works for the top module. It would be great if this feature could also work within flow modules to allow more precise debugging at deeper levels.
3. Prefix Flow Name in Log Messages
When using the log component, it would be very useful if the flow name was prefixed to the message in the console. This would allow users to identify which flow module the log message originated from more easily.
If you examine the console log messages, you’ll notice that the first two items are logged immediately, while the third item is logged as expected—10 seconds later.
@twoday-kss the link you shared is to your workspace? Can you share an embedded flow [1] instead? that would allow anyone you share the link with to see the flow vs having to invite people to your workspace.
Generally blocks execute when all of their inputs are ready/available.
Thank for that - indeed this is working as designed. The inputs for the log block are ready immediately, so you’ll see all the items logged in quick succession, but on the delay path, each item will be delayed 10s. What are you trying to do?
Thank you for the response! I was initially confused by the immediate logging of the first two elements. However, if this is indeed how the log block is designed to work, then there’s no issue at all. What added to my confusion was the fact that the third element was logged after 10 seconds, which I thought was intentional. That’s where my misunderstanding came from.
I’m having trouble using one flow as a module in another flow. The request block in the flow that I’m using as a module contains a body that contains the variable {{payload}}. Additionally, the pre-request script in the API request does a few data operations.
Remarkably, when I use it directly, the flow functions properly; but, when I use it as a module, the error is: Failed to parse body.