Space, Roles, Teams and Permissions

How would you design the following scenario in terms of Space, Roles, Teams, and Permissions?
We have multiple teams inside the company, each one representing a business unit with similar scopes (e.g: Finance, Marketing, Procurement, Development, etc). We would like each of these departments to be isolated from each other but also manage different permission for different roles inside each division and avoid having an excess privilege when they are not required. For example, we would like for the Finance division to have an isolated space with multiple projects and have some members inside the team, to have specific roles applied to specific projects (e.g.: team A from Finance has admin permission for all projects but team B, from Finance as well, has only permission to run runbook inside a specific project). Is this possible or, as permissions are space scoped, will I have to divide the Finance business unit into multiple spaces?

Hi @nicolas.spencer

Firstly, welcome to the Octopus community :slight_smile:

Thanks for your great question!

It sounds like you’re thinking carefully before configuring your Octopus instance. This is an excellent thing to do, and it’ll help set you up for success as you scale your use of Octopus.

Further, splitting each business division up is one of our recommended ways to configure the use of Spaces.

Now to your specific question to allow multi-team permissions within the space, the answer is that it’s possible to configure and is a common RBAC (role-based access control) technique used in Octopus.

Teams in Octopus can either be a system team, which can be used across all spaces, or a space team, meaning permissions for that team are applied to a specific space. We recommend creating space-specific teams whenever possible. That will allow you to manage the membership and permissions on a smaller scale, just as you require.

For example, suppose you want to create a Finance team A team. When you create your team in the Octopus Web Portal, you need to ensure that the radio button below is selected (it’s the default):

Then you can add Octopus users to the Finance Team A:

Next, you can include User Roles, which you can scope to different resources in Octopus.

You can scope the user role to project groups, projects, environments, or tenants:

It’s important to note that one item you mentioned isn’t possible as far as I know. You can’t scope permissions to the granular level of a specific runbook. You can scope user roles of Runbook Consumer or Runbook Producer to particular projects, but if a user has permission to view or run runbooks, they would be able to see all of them in a project. If that granularity is required, you could achieve it by having a project with a single runbook contained within it, but I’ll admit that solution doesn’t scale particularly well.

We also cover some common RBAC scenarios in our best-practices guide for users, roles, and teams

I hope that answers your question, but please let me know if you have any follow-up questions!


1 Like

Hi @mark.harrison thank you very much for your help. It is what I’m looking for.
I’m testing what you described but I can’t seem to find how to give specific project permission to one user.
I’ll walk you through what I’m doing.
I have a space called testing with 3 projects inside:

What I trying to do is to give the project viewer role to a user so it can only view the project MyFirstProject.
I go to user to invite a new user:

Invite user to this organization (I get 3 roles: Billing, Technical, Administrator) :

The new user becomes part of the “Everyone” team, which is a System scope team, with full access to all projects:

I can’t remove this user from this team so he will always have access to all projects.

I created a team called my-first-project-viewer with only viewer permission to the first project and added the new user to this team:

The user still has access to all the projects as I can’t seem to find how to remove this user from the Everyone group.

What am I doing wrong?


Hi @nicolas.spencer

Thanks for your reply!

Given your screenshots, it looks like you are using Octopus Cloud. A user needs to be in the Everyone group; since it’s a base team that everyone is added to when their user account is created.

The permissions model in Octopus is inclusive (and not exclusive). You can allow additional permissions through additional team/user role combinations, but you can’t perform Deny-type permissions through user roles.

As such, what you are finding is that the Everyone group probably has Project permissions, allowing the test user to see the other projects. The only way to change this is to modify the Everyone Group to remove the permissions.

For example, in my Octopus cloud instance, my Everyone team has the following permissions (under the USER ROLES tab):

  • Project Viewer
  • Environment Viewer

If you click on the overflow (...) menu on the associated role, you can change the scope of the user role(s) by selecting Edit or delete it completely by choosing the Delete option.

Please note: By changing the permissions on the Everyone team, you will be changing it for all group members. Just wanted to call it out before you made any changes!

I hope that helps!


Hi @mark.harrison

Thank you for your quick response. As a matter of fact, we will be using Octopus Cloud.

So, as I understand, a new user will always be added to the Everyone team when invited to the instance. As the Everyone team is visible across all spaces, and we don’t want to get user permission to other spaces, will it be ok if I remove all user roles from the Everyone team and manage permissions in other teams? What I want to avoid is giving system permission to users the are only allowed to view/execute action over a specific space.

One last question (hopefully), there is an Octopus Administrators team (System Team) which has only one member (octoadmin) and I can’t add myself. Who is this octoadmin user who has System administrator privilege?

Thank you very much for your help!

Hi @nicolas.spencer,

Thanks for your reply.

To answer your questions:

A new user will always be added to the Everyone team when invited to the instance.

That’s correct, yes.

Will it be ok if I remove all user roles from the Everyone team and manage permissions in other teams?

Yes, that’s absolutely fine. When a user logs in (after invite), assuming they had only Everyone team permissions (with no user roles), they could log in, but do practically nothing else :slight_smile:

There is an Octopus Administrators team (System Team) which has only one member (octoadmin) and I can’t add myself. Who is this octoadmin user who has System administrator privilege?

This is a service account with an API key that Octopus creates to manage/maintain the cloud instance.
Because Octopus Cloud is SaaS and thus a managed instance, we don’t give people access to the Octopus Administrators team. If you wanted to have similar levels of access to your instance, you can add users to the Octopus Managers team which is a team that has everything that account can do, except the Administer System permissions (which are reserved for Octopus managing the instance).

I hope that helps answer your questions!


Perfect. Thank you for the clear explanation, it really helps.


Hey @nicolas.spencer

You’re very welcome :slightly_smiling_face:

If we can help further, please don’t hesitate to reach out!