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.
Postman sells Pro subscriptions with the promise that “The Team Library allows team members to subscribe to shared collections. When someone subscribes to a collection, they get a synced copy of this collection in their Postman app. If they have edit permissions for the collection, they can make changes which will be reflected in everyone else’s collection copy too.” and now that I’m beginning to understand how Postman works, I suppose that’s technically accurate. But I don’t think I’m alone in feeling a bit duped by this statement after managing a team of users working with Postman Pro for a while now. Here is how I expected Postman team workspaces to work:
But here is how they actually work:
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.