Streamlined User Management
April 13, 2017
Effective user management helps administrators ensure they are paying for the right resources and enabling the right access in their projects. We’ve repeatedly heard in support calls and from our customers that they want capabilities to simplify this process in Visual Studio Team Services. I’m excited to announce that we have released a preview of our new account-level user hub experience, which begins to address these issues. If you are a Project Collection Administrator, you can now navigate to the new Users page by turning on “Streamlined User Management” under “Preview features”.
Here are some of the changes that will light up when you turn on the feature.
Inviting people to the account in one easy step
Administrators can now add users to an account, with the proper extensions, access level, and group memberships at the same time, enabling their users to hit the ground running. You can also invite up to 50 users at once through the new invitation experience.
User management with all the information where you need it
The Users page has been re-designed to show you more information to help you understand users in your account at a glance. The table of users also now includes a new column called “Extensions” that lists the extensions each user has access to.
Detailed view of individual users
Additionally, you can view and change the access level, extensions, and group memberships that a specific user has access to through the context menu provided for each selected user – a one-stop shop to understand and adjust everything a user has access to.
Feedback
Try it out on your account and tell us what you think by posting on Developer Community or sending us a smile. We look forward to hearing your feedback!
Thanks,
Ali Tai
VSTS & TFS Program Manager
I wondered if there was any guidance on the best way to manage large(ish) teams. We have ~20 developers spread over 3+ sites, with various other business, qa, management roles as well. Currently we have for example all QA in a VSTS Team Group, and that QA team is added to each [Project] Team. In theory that would mean that they would all receive any ‘team’ related emails – which I’m not sure we want.
Should the [Project] Team be only developers, or should all the qa/pm/business users etc be in that group as well? Do we need to explicitly add business users to the Contributor group instead?
I have a few questions about what you are describing. It sounds like you have several different types of users (Developers, QA, Management, Business) that need the same type of notifications and permissions within different projects in your account. Under a project, you’ve grouped them each into a VSTS Team. When creating the team, these users were automatically made members of the Contributors group of the project, so you should not need to also add that Team to the default project Team. If you are looking to make these permissions differ, you should go to the Contributors group and move the Team.
Typically, we find that accounts with your scenario will create an account-level VSTS groups (for Developers, QA, etc) and then add those groups to the according Admin/Contributor/VSTS security groups at the project level.
I am happy to hop onto an email thread if you would be willing to share further information about your scenario.
So I thought this looked reasonable at first, the search seems ok and the layout while not looking like anything else on VSTS (a little more consistency would be nice) seems functional.
So here is the ‘but’: when I tried to add a user I found that I actually have to add them to a project(s) security group.
We have a ton of stakeholders and users that need cross project permissions. We use account level security groups for this, to amke it easy to add and remove permissions. Now I have go remove your new mandatory Team Project group(s) assignment then add the Account group(s) assignment I actually want.
This is a bad change, adding users was a hassle this has made it worse. Either make the group assignment optional or ideally allow us to add users to account level VSTS groups.
Thank you for your feedback – we agree that this is currently a limitation of the new designs. We will be making group assignment optional with our next release – you can expect this to light up in your account within a month. In the meantime, you can use the old Users page by turning off the Preview experience to reduce this hassle.
Thanks Ali Tai,
I appreciate the quick response and the effort by the team in taking steps to make the onboarding experience easier.
With the new (in preview) “Manage users” screen, I now see only two choices for assigning access level: “Stakeholder” and “Basic”. How do select “VS/MSDN Subscription”?
Also, in that list of users, in the “Access level” column, there is no indication whether a newly added user with a VS/MSDN subscription has that type of VSTS membership. It says “Basic”, nothing more. For users with a VS/MSDN Subscription who were added to VSTS some time ago the “Access level” column says both “Basic” and “VS … subscription”. But for recently added users the extra “VS .. subscription” info does not show up.
Can you please also point to some relevant description of how membership is checked with VS Subscriptions, and how one can know if a user has a paid Basic membership or a “free” Basic membership thanks to a VS subscription.
Same problem, how assign VS Enterpise licenses?
Having used it for a few days essentially VS licenses are automatically detected and applied.
It would be nice to have a way of saying this user should have a VS Sub and let me know if he doesn’t, rather than just scooping up a spare basic license if there is one. It feels less clear in error scenarios and less deterministic right now, even if it is an attempt to hide complexity.
As Lex says below, choosing “Basic” would auto-detect whether or not the user has a Visual Studio subscription. After receiving feedback on this experience, we came to understand that this was very confusing. As a result, we’ve now updated the experience to show Visual Studio Subscription in the access level drop down as it did before, as well as adding more clarifying messaging to explain the content of the “Access level” column for subscribers (which can be seen by hovering over the error symbol).
With the new improvements, a user who has a “free” Basic membership due to a VS Subscription will have the subscription listed in the Access level column.
Thank you for the feedback!
One other quick comment. Appreciate you are making adding a Team Project group optional but it would be useful to either manage a users’ (account level) group membership from this screen or have a quick deep link to the security tab in the admin settings. Rather than navigate back and forth (or flip between different tabs).
Thank you for the feedback. To help me better understand the scenario, could you please describe what you would try to do with this deep link to the security tab from the user hub?
would love to see the ability to put a note on the user account i.e. as to why they have stakeholder or a basic license
generally I have a small bucket of Basic licenses spare, but in the instance someone adds a new member to their team it automatically takes up the basic license and I find it hard to track who this person was (especially when I have 200 users)
so I would like to
a) have all users become stakeholders by default, but a setting to determine what the default is would be nice
b) have a note field where I can explain why this person has this permission or possibly when add anything relevant to this user. (i.e. the date I need to downgrade/take away the permission so I can keep track
thanks
Thanks for the feedback. We don’t yet have plans to support creating a least available policy option in hosted accounts where users would receive Stakeholder by default. We are, instead, investing in being able to begin working towards users being able to assign a default license to AAD (and eventually, VSTS/TFS) groups. Would perhaps setting an All Users AAD group or Project Collection Valid Users VSTS group default license to Stakeholder fulfill your scenario?
As for being able to maintain a note field, we are currently designing a robust auditing solution which would reflect the history of a user’s access levels. One of the scenarios which we see this being useful for is understanding why a user has a permission/access level by being able to see who caused the change and when it was made. Is this something that you would be interested in providing feedback on?
Hello, this weekend is nice for me, for the reason that this occasion i am reading this fantastic educational piece of
writing here at my house.
Hi to every one, the contents present at this web page are truly awesome for people experience, well, keep up the nice
work fellows.