How can we improve Azure DevOps?

Hide Work Item Types (WITs) based on permission/security group

This suggestion is migrated to Developer Community. Please use below link to view the current status.
Within a team project, you should be able to specify who is allowed to create a specific Work Item Type.

A user should only see Work Item Types in the "New Work Item" menu (Team Explorer, TEE, Team Web Access), that the user is allowed to create.

611 votes
Sign in
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

Neno shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

As explained in this blog post (, we had updated the status of this suggestion to “Under Review” to let you know we are tracking it on our backlog. To better indicate which one we are actively working on or which ones are on our 6-month plan, we introduced the states “Started” and “Planned”. The goal is to give an update on in progress suggestions at least every 3 months. This suggestion is still on our backlog, but they are not part of the 6-month plan.

Ewald Hofman


Sign in
Password icon
Signed in as (Sign out)
  • Anonymous commented  ·   ·  Flag as inappropriate

    This would be very useful in my case for the same reason as Ben Richardson - I need to be able to enforce my process through programming rules, not rules for imperfect, lazy people.

  • Ben Richardson commented  ·   ·  Flag as inappropriate

    This would be very useful. I have stakeholders entering tasks instead of PBIs. They're not attached to anything so they get lost. It's only several days later, when someone asks where their work item is, that we learn they entered something in the wrong place. Training only goes so far when dealing with people, we would prefer a system fix to prevent this.

  • Thomas Pagram commented  ·   ·  Flag as inappropriate

    Is there any updates on the status of this one? It's critical for enterprise scale adoption of VSTS.

  • Ethan commented  ·   ·  Flag as inappropriate

    This still hasn't been implemented? I cannot find anything on how to do this except to "disable" the WIT, which isn't what we need at all! Any ETA for this?

    I saw that if I had migrated from TFS to VSTS I would have been able to do this with the custom XML process, but as I didn't I don't seem to have any options.

  • Mikael Petersson commented  ·   ·  Flag as inappropriate

    We have a strong need for this since we have work item types that contain information that we are not allowed to share with off shore employees. As it is now we have to remove permission to the entire project and all processes will be messed up. I was hoping for this in TFS 2018.

  • Anonymous commented  ·   ·  Flag as inappropriate

    It's also useful if the read permission for different work items types can be set.

  • Nikki Bridwell commented  ·   ·  Flag as inappropriate

    Adding the ability to assign work item types to user groups would be a huge help to our organization. I open our portals to our support team to enter a custom escalated work item type. The support team should not have access to enter issues as Bugs directly without being validated. Our dev team closes the escalation and creates a valid Bug to schedule. Now they can see all of our work item types from the widget on the dashboard.

  • Richard Shadman commented  ·   ·  Flag as inappropriate

    Tore: If you want to just hide them, import a new category xml with all work item types in the "Hidden" category. Hiding a work item across the board is fairly simple in that regard, but what would make this feature great is being able to make it group/team/security dependent.

  • Tore commented  ·   ·  Flag as inappropriate

    I am out of votes, but I would really like this one too. We have a few legacy Team Projects where we do not use Work items at all. It would be nice to simply being able to hide the "Work Items" hub and the "New Work item" menu in VS + the Work hub in TWA.

  • Keith Yin commented  ·   ·  Flag as inappropriate

    We really want to have a way to keep developers from seeing or changing the features/Scenarios that our Product Management group is working on...and we want to keep our Product Management folks from being able to see the tasks and hours developers are working on.

  • techSage commented  ·   ·  Flag as inappropriate

    Desperately trying to get my organization to adopt this, but it's a no-go without the ability to allow our customers to create and edit work items (bugs) without needing a paid account in VS Online. Company is even thinking about leaving JIRA because of issues with email notifications from the service, so the time would be right now to get this done. I'm sure there are plenty of orgs out there avoiding this service for this reason.

  • David Green commented  ·   ·  Flag as inappropriate

    TFS permissions scoping is a horrific, horrific experience. In my case, I need to mange two sets of teams with different access levels in the same project: Team A has unrestricted access to all work items, while Team B needs to be able to view/edit Bugs only. We don't want Team B seeing other work item types or viewing project tracking information like burndown charts and backlogs. Trying to get the appropriate permissions in place to accomplish this is impossible, as best I can tell, thanks to blanket permission settings that allow for the reading/editing of "ALL project level information" only, meaning users are given work item access in an all or nothing fashion. Whhhhhhhyyyyy!!!!!! Despite the promise of supposedly being able to use areas & area teams to create scoped access, the process as described on MSDN help sites is a byzantine maze of lies and deception. And this is coming from a TFS fanboy. Your enterprise clients need the ability to give users access only to particular work item types. MAKE THIS HAPPEN!!!

  • techSage commented  ·   ·  Flag as inappropriate

    Somehow I keep getting sent to this item as an answer by MSFT employees on forum questions regarding adding access to the limited access feature of TFS to TFService. This does not look like what I want to happen, but I will go ahead and vote for it in hopes that it somehow is bunched with the work that I would like to see happen.

  • KBower commented  ·   ·  Flag as inappropriate

    I want to be able to hide certian fields on work item forms from certain users...things like when a test cases steps have an action recording associated with them...resctrict other QA folks from being able to manually change the text steps.

  • etropic commented  ·   ·  Flag as inappropriate

    And or restrict types to teams. The team break out in 2012 is great and using team=area setup everything is separate. But some teams have many work item types that another doesn't need, and shouldnt create.

  • Richard Morgan commented  ·   ·  Flag as inappropriate

    We let our business users create user stories in TFS. We do not want our business users to be able to see our bugs and task break outs. We've tried to use are and iteration security but it's far too difficult.

← Previous 1

Feedback and Knowledge Base