Thanks for the feedback @gbadebo-bello .
For the environments, people have been in the habit of copying (not forking) an environment and just appending their names (env_bob, env_jane, etc.) I think this is a habit that spread on its own but didn’t have any real value or need. Educating people on the difference between initial and current values makes sense and is a good idea. Another bad habit everyone fell into was having all of the collections and environments in one large shared workspace. This is something else I am looking to change.
For client collections, I wasn’t clear. By “clients” I meant things like websites, desktop applications, etc. We have a few APIs and there are multiple applications (that we also develop & maintain) that use those APIs. As an example, we have a website with multiple pages and there was a postman collection created where each folder in the collection represented a page. The requests in the folder were the API calls made when a user interacted with that page of the website (ex: clicking a submit button). We also have a desktop application that uses the same API. In its collection many of the same API calls are made but they are in a different order because the workflow of the desktop app is different. In this case, I am not sure how best to maintain a “single source of truth”. If an endpoint changes, I have two different places to make updates. If I have a collection that is just all of the API calls and I fork that to make an app collection, the “watch collection” option does not really work because the app collections are going to make calls in a different sequence.
For the testing: As an example, sometimes I may want to simply run all of the requests and sometimes do some scenario tests. If I am just running all of the requests, I don’t care about the order but if I am doing scenario testing I want to run requests in a specific order. If the same request is needed in both cases, how do I prevent having multiple copies of the same request in the collection? It seems like there would be a risk that I could update one request but not the other. (Of course automated testing could catch this.)