[Feature Request] Conditional Workflows - Should be able to set next request under a different folder

[saiudayakella]

1) When there are same named requests under different folders of a collection, user should be able to set next request under a specified folder.

2) When a condition matches the criteria ( truthy or falsy) in a specified request under a folder, user should be able to navigate to a different specified folder

[sdnts]

@saiudayakella If I understand correctly, you're looking to specify a complete path of sorts when using setNextRequest, right?

[saiudayakella]

@madebysid Yes, in addition to setNextRequest("request name") should be able to specify setNextRequest(F\r), setNetRequest(C\F\r)

C- Collection, F- Folder, r-request

I reckon specifying request number instead of request name is already in your works.

[StaSotiro]

+1 This will be a very helpful feature, and have noticed quite a lot of requests on that as well.

[DenniLa2]

+1

[james7088]

+1

[matiashidalgo]

+1

[bbartoni]

is there any progress on this feature? It's really the missing piece in a wonderful tool.

[esztam]

+1

[atartanian]

+1

[guillaumelcv]

+1

[ravikalaa-krishnan]

+1

[jgstephe]

+1

[psolom]

+1

[fenixphp]

+1

[Bobatron]

+1

[schmitzdenis]

+1

[cbarrerah]

+1

[p00j4]

+1 is this feature live now?

[rizjoj]

+1

[igolus]

+1

[Animosa04]

+1

[cidmin]

+1

[nicholascelestin]

+1

[raghav19]

+1

[arif-arrijal]

+1, this feature will be very helpful

[Dangerunicorn]

+1 this feature would be very helpful to me

[ravitejapendyala]

When can this feature be implemented?

[shamasis]

When can this feature be implemented?

This is still a proposed feature. It’s yet to go through appropriate triaging to establish what the end experience would be like and how it would impact rest of the collection running aspects within Postman.

What would really help is if you (and others) elaborate on your use cases. That would strongly influence how this is built out. 😊

[raijinsetsu]

Our team uses the folder to separate APIs by version and name. Under those folders, we have the actions that we are testing. Most APIs have the same set of actions. Example layout, where (f) indicates a folder, (r) indicates a request, and the value in quotes is the actual name:

• (f) "v1"
  • (f) "user"
    • (r) "create (loop)"
    • (r) "get"
    • (r) "search by name"
    • (r) "search by email"
    • (r) "delete (loop)"
  • (f) "author"
    • (r) "create (loop)"
    • (r) "get"
    • (r) "search by name"
    • (r) "search by email"
    • (r) "delete (loop)"

Although we only need to specifically name the targets of setNextRequest uniquely, this is difficult to enforce without additional custom tooling. We would enact a standard that all requests must be unique (at least until we had something that was scanning the pre-request and test scripts for calls to setNextRequest and parsing it's argument to find issues). This leads to extremely verbose displays with redundant information:

• (f) "v1"
  • (f) "user"
    • (r) "create v1 users (loop)"
    • (r) "get v1 user"
    • (r) "search v1 users by name"
    • (r) "search v1 users by email"
    • (r) "delete v1 users (loop)"
  • (f) "author"
    • (r) "create v1 authors (loop)"
    • (r) "get v1 author"
    • (r) "search v1 authors by name"
    • (r) "search v1 authors by email"
    • (r) "delete v1 authors (loop)"

It makes sense to me to create a setNextRequestPath function or add a parameter to setNextRequest such that it would resolve relative paths (ex. "request" or "../request") relative to the current request's parent item and would also resolve absolute paths (ex. "/request") relative to the collection.

I saw mention earlier of being able to invoke requests from other collections. My team does not have a use case for that and I find it strange to need to be able to do that especially since it would not work in Newman, where there is only a single collection (AFAIK).

[RehanaMuhammed]

Even I have come across the same requirement. the test script sometimes demands to run the request which is in some other folder of same collection. WE definitely need some enhancement in postman.setNextRequest () function.

The suggestion given by @raijinsetsu makes sense. either this function should accept request full path or a new function to be introduced.

@Team, Please bring this implementation LIVE ASAP

[Gander7]

+1, This is very hindering in our SDLC. Definitely our biggest pain with postman.

[olegkorol]

Are there any news here? Thanks a lot in advance!

[ghobadkhan]

This is definitely a big requirement. Please hasten its deployment.

[anthonyT0]

Any news here about that feature? Thanks a lot in advance!

[StevenR152]

I'd love this feature too, it's almost a dealbreaker for our team.

We want to define a bunch of shared folders of functional components, and then be able to call them in different other collection workflows.

[droduit]

Definitely need this feature :)

[mallechilie]

What would really help is if you (and others) elaborate on your use cases. That would strongly influence how this is built out. 😊

For my purposes (a migration) this would help greatly:

I use folders to have all authorization in one place

- old site
 - get general info for preperation
 - get ticket info
 - get ticket details
- new site
 - get general info for preperation
 - post ticket in new format
 - post ticket details => pm.setNextRequest("get ticket info")

So as you can see, I'd like to loop back to the first request, which is currently impossible if I want to keep the folder structure.