We’re just getting to grips with Team Workspaces and it seems that Forks of Workspaces may be what we’re looking for (flexibility, but retaining control of source). However, I have a Q regarding making this available to non-Team members. Let me explain…
We have a need to get internal developers and external parties (e.g. testers, stakeholders) access to a particular Workspace. However, our Postman Team is already a bit cluttered with past workspaces for older projects, primarily used as a way to keep “master” copies of workspaces/collections (we prefer to keep the “master” Workspace/Collection within the Team environment so that we don’t lose it).
We can see that Team users can easily click to “fork” collection(s) to other workspaces. However, there are external (NON-Team) users that we’d also like to be able to Fork the same Team Workspace (we don’t want/need to make them all Team users).
So I guess my question is…
Is there a way for non-Team users to be able to “fork” a particular Collection that resides within a Team Workspace WITHOUT being invited to the Team/Workspace?
They would need to be part of the Team, to fork a element in the Workspace. Must the same as you wouldn’t be able to fork anything from one of my Team Workspaces.
You could create a Public Workspace and fork the Collection in there but that then open it up to anyone accessing it (People you want to and people you may not want too).
What are these external people doing on that forked Workspace? Would their changes be merged into the main Collection?
If not, couldn’t you share that Collection by exporting it via a JSON file or using a sharable link with the Collection Token attached to limit the access.
Thanks for the suggestions (+prompt response), much appreciated.
Ok, that’s what I figured (need to be part of Team to fork).
Privacy is key to this project, so no, a Public Workspace would probably not be suitable.
(How “Public” is a public workspace? Can it be found by anyone, or would you need to know the URL/name?)
Either way, your question re: the nature of the external users having forked Workspaces made me realise I missed a key detail…
We want the various users (Team and External) to be able to have two capabilities:
To be able to work on a their own copy of the “master” Collection
(e.g. can tweak/test requests without trampling over other users), and…
To easily play catch-up with any updates/changes from the “master” Collection.
This is what appealed with the “fork” functionality TBH (plus with the added ability for users to suggest changes via PR as a bonus)
So, am I right in thinking that that really only leaves us with Export/JSON option?
(which sadly will make it harder to keep ppl in sync)
Looks like given the fact that these external users are not part of the team, exporting a JSON file is going to the only option.
You could have handled that and have external users taking advantage of our forking/pull requests/merging functionality if the Collection was in a Public Workspace but that’s not going to be something that can happen here.
I’ll still have a think about some different methods though
