As a long time fan of Postman, I convinced the consulting organization I work for to purchase Pro licenses and adopt Postman into our standard development lifecycle. The vision was that Postman would allow team members to onboard into an existing client and get built-in visibility to how that clientās applications function. At the same time the organization would be building a wealth of internal documentation and knowledge transfer material to outlast employee turnover and application versioning. My real-world experience has seen these promises not live up to expectations, and Iām posting this here as a plea for the Postman organization to consider improving the product so that I can make the case for Pro renewal next year, because at the moment I canāt.
This is a significant shortcoming for those of us who support a team of Postman developers.
Collections, environments, monitors and mocks in shared workspaces are tied to a team member. If that team member leaves the team, Postman allows the organization to lose data because environments, monitors, and mocks are deleted. The delete process has a warning (So and So has 23 shared collections. Shared environments will be lost), but not enough actionable information to address the issue. The only surefire way is to export all collections, environments, etc from all shared workspaces, then try to figure out what went missing after the removal and re-import. Of course, whoever re-imported them is now the owner, and if they leave the organization the same problem occurs again.
Collections built in a local workspace and āsharedā with the team are no longer scratchpads for the sharing party because the team will receive updates made in the private workspace. This leads to devs creating a new workspace or collection and developing locally until they are ready to share, then copying the collections or requests over. The same fine control is not possible with environments without duping an entire environment
Collections and environments created directly in a shared team workspace have no replicated location which survives the removal of the team member from the team. If a user creates content directly in a shared workspace and they leave the organization, removing them from the Postman team means that all the work they did is gone forever.
I know that there are workarounds to protect data - a team can turn on github integration or write custom code against the API to back everything up reliably. But I donāt think that users should have to consider data loss prevention for a paid product where the vendor owns the back end.
Instead Iād like to see Postman team workspaces be owned by the organization rather than a team member. Team workspaces are the source of truth which authorized team members can write to and manipulate directly. I see it as the master branch in a gitflow world, where participants can either hotfix by making changes directly in the team workspace or add collections, environments, mocks, and monitors to the team workspace from their own workspaces using a copy action rather than a share.
As a business owner I need to be able to retain the work my users produced while they were employed by me. The current architecture doesnāt guarantee that I will without taking specific steps outside of the application. The sales material, documentation, and Postman web site donāt address this directly, which is a problem.
Iām curious to know if the Postman team recognizes this as a problem for itās pro customers.
@Josh_K - This is really great feedback, thank you for taking the time to frame up this issue.
We have indeed heard similar feedback from other Postman teams, and in fact the recent releases have focused on smoothing out the collaboration workflow for teams. You may have already seen some of this activity:
the latest release for role-based access control (RBAC) was intended to eliminate the concept of owners and introduce the concept of roles. This should address the first and third bulleted issues you bring up related to losing organizational data when someone leaves the team.
also recently released was forking and merging so you have finer control on what and when to share your collection updates. This should address the second bulleted issue related to having a separate scratchpad to tinker with stuff before sharing with the rest of the team. Incidentally we also have API versioning in planning (not yet released) that will further enable you to track changes and communicate more explicitly.
The Postman team has been busy with some of these recent releases (and a number in the pipeline) to address these particular team workflow issues. And itās next on our list to better communicate the how and why of these new fangled features - stay tuned.
I want to reiterate that this is really valuable and constructive feedback for the Postman team. Thanks for being a long time fan of Postman, and I hope you continue to share your experiences and use cases, since that is what actively shapes the Postman roadmap. So if you have a chance to try out the RBAC, forking, or want to weigh in on features that are in development, let us know what you think.
Iām not sure I understand how RBAC addresses my concern about data loss.I upgraded our team to to version 7.0.6, cracked open a team workspace, and directly created a new sample collection inside it. This is what it looks like:
As you can see, this new collection still shows me as the owner. I can only assume that if I am removed from the team, this collection would have to be transferred to another user to prevent it from being deleted. This should be simpler - the team workspace should be a stand-alone container and the contents inside it (collections, env, mocks, monitors) should have no dependencies on external users.
What I also find odd in this scenario is that this collection which I have just created inside the team workspace presents me with the option to āremove from workspaceā in addition to āDeleteā.
I assume that if I delete this collection itāll go away forever, but what does āremove from workspaceā mean in this scenario? If I remove the collection from the workspace, does it still exist somewhere, linked to my account? Is it recoverable?
Forking, merging and versioning are all interesting features that would probably be very useful if the core storage, ownership, and sharing concepts were solid.
What happens when someone leaves your Postman team
To clarify a bit regarding data loss for RBAC-enabled teams (those who have migrated to v7.0 and later).
Personal collections: Collections that only exist in someoneās personal workspaces could leave with that person when they leave the team. The person leaving will retain those personal collections if they can access the Postman account associated with those personal collections, for example they created their Postman account with myAccount@gmail.com (vs. myAccount@myPreviousCompany.com).
Team collections: Collections that have been created in, or shared to, a Team workspace will remain with the Team. The person leaving the team will no longer have access to those collections. Other team members can view the collection in the team workspace. If team members have edit permissions, they can edit the collections. If they have view-only permissions, they can duplicate the collection in order to have edit permissions on the new duplicate.
@Josh_K - did that second bit about the Team collections satisfy your general use case? Or is there more that your team would like to see with regards to the team workspaces?
Remove from workspace vs. Delete
Regarding the āRemove from workspaceā and āDeleteā options, some folks find that confusing, so both actions display confirmation prompts to further clarify the respective intentions.
āDeleteā means itāll go away forever.
āRemove from workspaceā means that the collection will be removed from that particular workspace. The same collection (and environments too) can live across multiple workspaces. And yes, there is a view in the web dashboard where you can view all of your collections.
Thank you @jetison - it does address my questions. Iāve been meaning to find time to do some validation testing on this, but I just havenāt been able to.
I think there are a couple of UI tweaks in this thread :
Remove From Workspace doesnāt make sense if itās the last workspace a collection is in (it effectively becomes delete, but itās less obvious that itās destructive)
The owner property on collections created directly in shared workspaces seems to be misleading or improper. If team workspaces are RBAC I think the āownerā UI interface should probably be ācreated byā or something that doesnāt carry over paradigms from pre-V7 Postman
Iāll do some validation testing on ownership and removing team members this week and report back with my findings.
@Josh_K Thanks so much for the detailed feedback! Regarding the two UI tweaks you specified:
Weāre working on identiifying dependencies across Postman entities, e.g. workspaces and collections, and looking at the best possible way to avoid a situation where you have a collection which isnāt in any workspace. Disabling the Remove From Workspace action if itās the last workspace a collection is in seems like the obvious choice, but weāll keep you updated on how we proceed with this.
Spot on again, weāre trying to move away entirely from an Owner field to a Created By field. There are some areas which weāve missed out in the 7.0 release, but weāll be cleaning those up in the coming releases.
