thanks for the mention @danny-dainton. I have to admit that I do find Postman pretty absent on nice re-use of various parts in the system, in particular code re-use, request re-use and dynamic flow execution. I have been battling with it for over a year and found some workable work-arounds. It’s all still a bit rough, but I want to start writing them up here over the next few months.
In essence, we have teams with dev’s and QA’s all adding to the same collection of grouped and alphabetised end points. Many have useful test scripts to save stuff to the globals and/or environment, but inherently it is a manual testing tool, where the user needs to perform the right sequence of steps to login, gather info, do stuff, and logout.
You’d think setNextRequest would automate something there, but alas there are conditional flows depending on responses that can not easily be predicted (eg multi-factor authentication responses that seem to appear out of the blue)
So the task was to figure out some means by which we could effectively implement a proper state machine that sends requests and then has separate response handlers for various scenarios.
I have managed to cobble something together, and it’s starting to show some dividends for us. But it’s an ugly baby right now and needs some work before I share it here.
I’m hoping to first write up something on my idea of a Postman Object Model approach, where you use a shared code library (stored in a global string) and actually write little classes in the library that know how to store themselves in globals, but hide the details. I’ve got a proof of concept working for me, and seems a cool way of being able to create persistent objects between pre-request and test scripts, as well as other requests. It effectively creating a common global scope for javascript objects.
I’d imagine someone will figure out that all this can only be done using eval, which is true, but hopefully I can convince people that that isn’t necessarily evil. I was a bit worried about storing too big a library in the globals, and that it might impact on performance. Luckily, for me, evidence suggests that’s not the case, my code library is now over 3000 lines of code, and speed doesn’t seem to be impacted in a material way.
BTW: It’s no unintended pun that it is also a P.O.M, as per the famous Page Object Model that our UI automation counterparts like to use 
But bringing it back to Collection & Folder elements and keeping it DRY, my framework hinges entirely on using collection level pre-request, and test scripts. These hook into scenarios provided in an external json data file, which call internally configured user actions that contain multiple response handlers. The response handlers can cue up a further request or pass to the next step in the data file. I, pretty sure I wouldn’t managed to get it to work without being able to write a script that I can specify to run for every request, the collection & folder elements are awesome! 
