My company is using Flows to help our users execute on functionality that is somewhat difficult to do on their own. Our intention is for them to clone our flows and utilize them in their own workspace.
In v 11.29.3, you changed how collections are used within cloned flows. It appears that you now copy the required requests into a new collection.
This causes a disjointed / duplication of collection if our users have already forked our collection.
The collection settings that we have set are lost when this clone happens. So our users have to reconfigure authorizations and variables.
Above all, I wish that users could truly fork our flows (and get updates when we make them)…but I understand how difficult this could be.
At a minimum, I would like for them not to have to continually fix their auth and variables.
Looking at your flow, the issue might be using the Start Block in “Any data” mode.
I would recommend toggling off this setting and adding an input to the start block named data with a type of “Record” to see if this addresses the issue you are seeing. (See screenshot below).
This mode (accepting “any” data) is really only intended to be used with a webhook.
It would be great to import environment variables, or vault variables, or builtins like {{$guid}} in either an evaluate block or as a general block to be used.
It would also be nice to have pre and post request script blocks, or even full reusable request wrappers to allow for manipulating a request without updating the request in the collection.
Hii,
I am new to community but i do use the postman for quite a while . I just have suggestion While working with query parameters, I noticed the ability to define enum-like values (dropdown options) which is super helpful. I think it would be great if a similar feature could be added for the Body > form-data section. For example, when sending keys like type or category, it would be really useful to predefine possible values as enums, so we can pick from a list instead of typing them manually every time. It’ll reduce human errors and improve consistency during testing.
My suggestion would be that archived snapshots shouldn’t be visible/useable in the dropdown for the flow module block. Once you get more than like 8 snapshots it takes up a lot of the screen and can confuse users. I think if a flow module already has an archived snapshot set on it, that’s fine and you can error out with the “I can’t find this” like normal, but you should then be able to easily see and choose a snapshot that won’t have that error when you check the dropdown at that point.
