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 
@kevinc-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.
1 Like
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 
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?
Sad.
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 
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?
Welcome to the Postman Community! 
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 
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.
1 Like
Thanks for the response!
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. 
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.