What Happened to Sharing a collection/environment across Workspaces

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 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?

Can’t we just allow customers to adopt one model or another? Allow the confused people to restrict the linking/sharing but allow the rest of us to keep this important piece of function?

Is there any progress on bringing the feature back?

bumped! This has made managing collections much more difficult for my team

Thanks Postman, for making things that little bit harder :clap:

I’m assuming, given the lack of activity here, that there’s no fix or simple workaround to keep sharing/syncing collections in the old (simple) way?

Hey @daniel.loiterton :wave:

Welcome to the Postman Community! :postman:

This thread has been open for a couple of years, is your question based on the original topic or related to something else you’re seeing now?

Just trying to understand the context of your current issue :pray:

Hi Danny,

Same as the others. We have several shared collections across a couple of workspaces. This morning I needed to share a new collection (first time I’ve done this for a year or so I guess) only to find that option has gone missing. I quickly worked around it by exporting/importing the collection, but now the collection will not stay in sync across the two workspaces, like our other shared collections. Annoying.

Hey @daniel.loiterton

Thanks for the response! :pray:

That functionality has been removed for a while (A couple of years), there was a flip side of this where users were deleting a Collection shared to several Workspaces, which essentially was the same Collection and this would delete all the other references in the other Workspaces. Not a great situation. :cry:

There were measures in place to prevent this but this unfortunately, didn’t prevent it from happening.

I would recommend using the Forking and Merge feature to bring the Collection or Environment into another Workspace. You then have the ability to make changes to the ‘main’ collection and pull those into the fork or vise verse.