What Happened to Sharing a collection/environment across Workspaces

If you have 30mins, I’d appreciate it if you could hop on a call and discuss this issue.

You can select a convenient time using this link: Calendly - Ramji Enamuthu

This is totally optional of course. I will post periodic updates on the thread as we think through the problems raised here and plan solutions.

We found a simple solution to these feature changes that will suit our existing team workflow.

Instead of sharing an API Collection from our company workspace into “My Workspace” we are simply going to make all of our changes directly in the company workspace.

We will essentially eliminate the use of “My Workspace” entirely, which allows us to collaborate in the manner we are used to.

The only change our developers have to make is a 1 time transfer of Environment settings from “My Workspace” into our shared company workspace, specifically entering their secrets under “Current Value,” which does not get saved or shared back to the workspace.

1 Like

That’s great to hear. Do you fork a collection within the same workspace and PR the changes to make updates?

No, we do not currently use the fork collection functionality and we are unfamiliar with how PRs work in Postman.

My manager is interested in using forks for his own testing purposes, but he does not intend to publish any of his changes back to the company’s shared collection.

We may experiment with the fork + PR model, but for now we are happy to continue operating under the classic paradigm that our whole team has been trained on.


You made this change without even announcing it in release notes. This kind of massive change takes care & communication and as far as I can tell there was zero. Took me a long time to even find this thread to figure out what is going on. Like bkirsch, this has completely broken the cross-team workflow we had established (which was hard enough to get everyone on board with in the first place).

In addition, you removed the “Remove From Workspace” option in the collection context menu. I have many collections shared into my personal & team workspaces and I can’t figure out how to remove them at all without deleting the entire collection from all workspaces.

1 Like

Please bring back the ability to “Share” Collections and Environment Definitions across Workspaces else we going to move to SoapUI.


BRING BACK the share ability, as you can see there is a huge demand for it and is the crux of why we selected Postman in the first place.

We are paying customers and removing key functionality is not acceptable.

1 Like

It doesn’t need that level complexity, bring back the sharing option !

1 Like

As a Product Manager you should have opted to give your customers a choice to keep the existing share or move to the Fork/PR method.

Taking one lot of customer feedback and impacting the rest of your client base is not a wise choice.

You say you made the change due to customer feedback, well we are all giving you some very important feedback… return the functionality as an option so that customers can select their preferred method.

1 Like

I agree 100%. Removing a feature rather than providing an alternative and giving people the choice is extremely disruptive and a hasty decision without thought to the impact it would have on people who were using the previous solution well.

I really hope Ramji considers re-instating this as an option for users (even if it’s off by default)!

Guys it’s very frustrating, we used a lot this feature and now there is not a good and simple alternative. Bad way to manage a breaking change

Hey everyone!

I understand how frustrating it is when things stop working and workflows have to change. It’s our effort to make things easier for everyone that we made this decision. We’ve recieved a lot of feedback from users where it’s often times confusing and a challenge to keep collections in sync with one another.
It’s helpful to maintain a “single source of truth” which is why we opted to rely on Forks and Pull Requests much like Git and similar version controlling tools/methods.

Since a collection could exist in multiple workspaces and can be edited instantly, often times users found it hard to maintain tighter controls and ensure that a single edit doesn’t break their entire workflow. Forks with proper merge checks and a review process makes this a lot easier for everyone.

As an alternative to sharing collections, you can fork an environment or collection to a different Workspace and also create a Pull Request to contribute changes back to the “Master” collection. We see this model as being a trade-off between enabling teams to have tighter controls on their Collections/Environments while also being able to collaborate.

Here’s a link to our documentation that goes into detail on this and we also have an upcoming video that may be helpful :smile:

@kevin-postman What it seems that you are missing is that a lot of folks liked the “share” feature and for their own reasons do not want, need or desire to use the “fork/pull requests”.

For the usage model and manner in which Postman has been implemented in my organization, forking and pull requests add an additional layer of work, with no “REAL” benefit but it has greatly increased the work load of my team in managing our collections.

It would be great if you could bring this back and put the requirement to use Forking behind a permission. that way organizations that want to enforce its use can implement it but those that don’t, can continue to use Share as it was originally implemented!

The manner in which this change was implemented, rolled out and communicated has done nothing but detract from the user experience, NOT enhanced it.

The continued “push” to use forking is distressing… It is not a “Trade off”… it seems like an “our way or the highway/take it or leave it”.

I understand the idea behind the feature because it was always weird for me to work using a collection shared from my team workspace to my personal workspace and any change I did “locally” would alter the collection for everybody. A forking model seems decent enough, especially if there are some sort of visual cues about upstream being changed and there’s the ability to merge those changes back, a la git.

However, what’s really, really bad is how the new feature works for people that have already used the “share” feature because there’s no way to remove the shared collection from the workspace. Even deleting my personal workspace caused the shared collection to be deleted from the team workspace, together with monitors, environments and whatever else I shared to my personal workspace. Collections I can recover from trash, but I can’t recover monitors or environments.

I understand that Postman has to evolve to be competitive, but removing features without some sort of deprecation warning or upgrade path is really, really bad practice. Most of us use Postman professionally and pay a monthly fee to have a reliable working tool. We don’t want bleeding edge software that we have to re-learn and understand every couple of months because this means we’re not productive. Look at all the professional tools out there and you’ll see that they rarely change and there’s a good reason for that.

Taking this away is just really bad. I get the forking feature, it’s fine if you want this behavior. But that doesn’t mean that many of your customers use and appreciate the sharing feature.

I like to have my custom workspace that contains just the collections I want, but that doesn’t mean that I want to work with forks or anything, this is just an organizational tool. I don’t see a single good reason why you would take that away from us :frowning:

Instead of now just working on a shared collection, you are forcing our team to either all work in the same giant workspace, or jump through tons of hoops so that everybody can be sure to work with the latest set of endpoints in the “master” collection. There is literally no justification to force that “feature” on us.

Please bring back the sharing functionality. This is a major step backward and a hindrance to workflow. The fork/pull request option is significantly more work to accomplish something that the sharing feature made so easy for so many people.

We want to split workspaces based on teams working on different slices of product but they share environments. Without the ability to share the environment, maintainability goes for a toss.

We recently introduced the capability to fork environments. You can use it to reuse an environment across multiple workspaces: Introducing Environment Forking and Pull Requests | Postman Blog

Environment Forking is a good solution if this issue is resolved

Any update on when this bug will be fixed?