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.
2 Likes
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
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.
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.