Hi guys
Currently all the members of my workspace have access to all the projects. I need to create a project and only give access to a limited group of members in my workspace, how can I do that?
2 Likes
Great question—this is something we’re actively tracking! We’ve heard it related to JV projects, nda sensitivity and competitions. No doubt you’ve got something exotic in mind, Victor? Perhaps a clandestine digital twin for an intergalactic colony, or a stealth-mode AI that predicts which architects will hit their deadlines? 
Right now, the only way to restrict access to a project within a workspace is by creating a separate workspace, which we know isn’t ideal.
Standard Speckle rules apply here: we think (there is no we, it’s just me, my opinion, speculating in the open, ready to be shot down by @benjavo ) this is how it might work in the future:
- User Groups within Workspaces—Workspace admins define groups like R&D Team, Secret Squirrels, Digital Wizards, and The Gherkin Review Board (or something more serious).
- Project-Level Access Controls – Project owners decide which groups (or roles? teams?) get access instead of making everything workspace-wide.
This also ties into another significant need: individual projects stored in specific data regions (e.g., a project in Brazil, while the default workspace is in the EU).
Short answer: You can’t do this right now.
Longer answer: We’re working on making it possible!
We would love to hear what access controls work best for you! 
Hey Victor. As Jonathon writes we’re actively discussing how to support this and it will be a priority soon after we finish some other work. The simplest solution I can think of is to make projects in workspaces work more like projects outside workspaces by giving the project owner and workspace admins control over who have access to a project: A) Everyone in workspace have access, B) Only invited people. But as Jonathon also writes there’ve also been separate requests to allow defining groups/teams and “folders” of projects that only some members have access to. But this might just be an additional feature and not instead of.
Would be happy to get your input.
1 Like
There actually is a way around it now. If there are people you want to only have access to some projects in your workspace you can make them a a Guest member. Guests can only access the specific projects they’re invited to as opposed to Members who can automatically access all projects (this is what’ll probably change soon though). But bear in mind that a Guest is not allowed to create new projects in the workspace and when they join your workspace they also don’t need to authorize through SSO (if that’s something you’ve set up on your workspace).
The Guest feature is really meant for external collaborators. We might even rename it to this soon to remove confusion. Anyways, it can be a way for you to solve this problem now while you wait for us to give you more project visibility control for all types of members.
1 Like
Thank you for the prompt reply. I’ll wait until you have figured it out. Some notes:
- It’s good that the approach now is “open-first” as in everyone has access to everything in the workspace.
- It feels weird though that the list of members of all projects within a workspace is equal to the list of members of the workspace. I think this is misleading as this is almost always not true.
- Ideally we would be able to make a project inaccessible only in specific cases. (an admin feature)
Keep up the good work @benjavo. I will ping you again if we get comissioned for an intergalatic project @jonathon
1 Like
Re point 2; When a project is created, all workspace members are automatically added as project contributors. It basically loops over all the workspace members and explicitly adds them, this gives them access to the project by default. However, after creation you can remove specific members from the project collaborators list to remove their access, unless they’re workspace admins (who will have access regardless).
1 Like
I’m guessing what’s unusual here is seeing the heads of everybody who has access to the project which is quite different to let’s say a window server directory where everyone has access but you don’t see their little heads.
But, we’re not trying to show who is the project team but transparently audit who has access to this data — maybe it is an overshoot and we can consider something else( declaring this is the project team versus who has access). We just don’t want things to be too complicated.