Today, we’re excited to announce that users with the Stakeholder access level can now be administrators in Visual Studio Team Services (VSTS). With these upcoming changes, Stakeholders can administer access levels, permissions, and settings – if they have been granted permissions to do so. Previously, they were only able to invite users and assign them an access level, and could never act as full administrators without also being granted a Basic access level.
Why change?
When we first introduced Stakeholder in 2014, the goal was to allow people who just wanted to track progress or file an occasional bug to do so without having to pay for a Basic access level. Since then, we’ve seen it widely adopted to allow project stakeholders to collaborate with their teams easily, and for free.
Despite this success, we’ve heard feedback that some customers want to allow Stakeholders to be admins in their account – they have users who just need to manage security and permissions and don’t want to pay for them to do so. We think this makes a lot of sense and will make it even easier for teams to collaborate with VSTS.
What are the specific changes?
The additional actions that users with the Stakeholder access level will be entitled to are:
- Create new projects and teams
- Edit account, project, and team information
- Add users to projects and teams
- Manage the permissions of users and groups on the Security pages
- Manage settings on all the Settings pages (i.e. Work, Notifications, Services, Release Retention etc.).
- Add, update, delete, and manage Dashboards
These changes will go into effect in July, with the exact date determined by our deployment schedule. We’ll update this post and our docs when the changes are in production.
Will this affect me?
If you have any users with the Stakeholder license in an admin Security Group, they will get more access then they do today. The default admin Security Groups are Project Collection Administrators, Project Collection Build Administrators, Project Administrators, Build Administrators, Endpoint Administrators, Release Administrators, and Team Administrators. If you have custom Security Groups that grant admin permissions, Stakeholders in those will also be affected.
To prevent these changes, you can take your Stakeholders out of these groups, or set up custom groups as needed.
If your users with the Stakeholder access level are not in any admin Security Groups, these changes will not affect you. This is because in VSTS, a user can only take an action if their access level grants the action and their permissions Allow the action. The changes we are making change what the access level grants. They do not change what permissions your users have. As an example, let’s look at the ‘Create new project’ action:
Grace has a Stakeholder access level and is in the Contributors security group. Because neither the Stakeholder license nor the Contributors security group grant ‘Create new project’, she can’t take that action. With these changes, the Stakeholder license will grant the action, but the Contributors security group still will not. So Grace still will not be able to create a new project.
You can learn more about how permissions and groups work, or view our default security groups.
Thank you! We’re excited for these changes and hope they’ll help make VSTS an even easier product for teams of all sizes to use.
I want to become the stakeholder.
Indian Fastival