Just wondering is it possible to configure following setup:
Members of team A can deploy to test server A, members of B to test server B
When everything is ok both teams A and B deploy their project to same staging and then to same production
The question if how to make, if it possible at all to users from A see only A and same for B, so no chance to deploy something wrong by mistake to others team server
Thank you in advice
Hi Marchenko,
Thank you for getting in touch,
It’s definitely possible to set up this permissions structure.
Octopus gives you great control over users and what they can do what in different environments. You can control this by scoping Teams & User Roles to different Projects/Environments. Using a mix of permissions and custom Teams, you are able to create complex permissions to accommodate your goals/requirements.
Here is a link to our documentation that relates to how you can edit the user permissions on the Octopus server.
Below I have also included a link on how you can set up a user with mixed environment permission, the concept, however, can be used for any permission scenario that you require.
As an example, within my environment, I was able to create a user named “Dev Ops” that had full administrator permissions (minus the ability to edit user roles to prevent the user from manipulating the permissions I put into place) which belonged to a newly created team called “Dev Ops Administrators”. The Team “Dev Ops Administrators” was scoped only to my “Testing” environment and not my “UAT” or “Production” environments. As a result, the User was able to create a release and deploy to Testing but was not prompted to deploy to “UAT” or “Production”. (It’s also possible to scope the Team for specific Projects, Project Groups and Tenants)
It’s worthwhile to mention, you could also include a manual intervention step to introduce a sign-off procedure, this can be used to avoid deploying to your production environment in error.
Please be aware, however, using your example with the above permissions, this will cause users in Team A to not be able to view the Team B environments outside of the deployment process, so if this is something you still require then this will not work accommodate your scenario.
I hope this helps!
If you require any further assistance or clarification please let me know 
Kind Regards,
Reece
Hi Reece thank you for suggestion but there is one thing still left
Lets imagine that we have following environments (and their servers):
Staging (serverA, serverB)
UAT (serverUAT)
Production (serverProd)
While creating team you are selecting environment rather than servers, so it is not going to work for this setup
To answer why at all we need such setup: team A and B works on same code base but with different pieces, so idea here is that they allowed to deploy their feature branches to their test servers, and when they ready and push changes to master they are going to UAT->Prod journey
Hi Marchenko,
Thanks for getting back to me regarding this,
Is it possible, using the aforementioned suggestion, that an environment could be created uniquely for both servers?
You could opt to make both environments be optional within the lifecycle, this can accomplish this by creating a custom Lifecycle.
I’ve included a screenshot below of how this appears when creating the Lifecycle;
[Refer to Screenshot 1]
When deploying your release, you can select the specific Environment you wish to deploy to, or you can deploy to all environments.
I’ve included a secondary screenshot here that highlights this;
[Refer to Screenshot 2]
I hope this helps if you require any further assistance or clarification please do not hesitate to reach out.
If I’ve misunderstood in any way, let me know 
Have a great day!
Kind Regards,
Reece
Reece thank you for your suggestions at least it might be a plan B in our case, it is not exactly what we are looking for
I’ll try to describe situatio, I bed that we are not only one who are trying to build this.
So imagine that we are both working in same company but in different teams and building same site which has two pages a.html and b.html (so one of html is mine, other is yours, both living in single repository)
There some a CI configured that builds each commit adds branch name as version postfix and pushes packages to octopus
On octopus we have channels which do not allow anything except master to be deployed to UAT/Production, and anything else can be deployed to Test environment
We both have own project managers which both want us to make some changes to site and wish them to be deployed as soon as possible
So we both making our branches from master, deploying them to our own test environments, when work is done we merge it to master and deploying release to UAT and then to Production
In configuration you have described there is a human factor, in case I by mistake deploy release to your test server you might get bazillion bug reports from qa and project manager, and only when you will find that I did this you will be able to at least redeploy your branch to your server and ask everyone to recheck their reports
Will be nice to somehow restrict this, or may be do some other setup
Hi Marchenko,
Thanks for getting back to me in regards to this, I greatly appreciate your patience in this matter.
The other alternative would be to perhaps duplicate the steps and scope each to the appropriate role/channel combination to ensure it only runs on the right machine depending on the channel.
Each machine would have to have a unique role in this case.
However, this wouldn’t work in your scenario as using the role/channel step scoping won’t restrict users from deploying to the wrong servers.
It’s possible that this may be solved by some work we have in our roadmap regarding ‘Spaces’, at a high level introducing Spaces into Octopus should allow you to further break down the permissions within Octopus as a way of creating grouped teams for your developers. Their space will have their projects, environments, dashboards, lifecycles etc. No ETA on this at this stage but something worth mentioning in the interim.
I’d recommend visiting our Community Slack Channel, this channel is driven primarily by the community though Octopus staff do monitor it fairly often to make sure discussions are relevant and on the right track. It’s possible another Octopus User could shed their opinion based on your goals/requirements.
If you require further assistance or clarification please let me know
Kind Regards,
Reece
Agree with you, at least someone in future might find this thread helpful
At moment it seems that there is no right answer for this, so after showing your idea with optional channel to one of our developers we decided to try this approach, at least there is one plus in it, in case there is something critical there is possibility to deploy changes to all servers in one click
Thank you in advice
Alex
PS: thnx 4 slack channel - hope will find new friends there
We have a similar setup, only we use Tenants for the environments that require separation.
You could have a Test environment with Tenant A and Tenant B. Each team only has permissions on their Tenant. Then for UAT and Production, perform an Untenanted deployment.
