Dev Ops Help

Contents
Wikis, Search, & Navigation

Get started
Set your preferences
Set personal or team favorites
Understand your default permissions
Connect to a project
Navigate the web portal
Get started with Search
Create a wiki for your project
Wiki
About wikis, READMEs, & Markdown
Provisioned versus published wikis
Get started
Add & edit wiki pages
Publish code to a wiki
Wiki file structure
Create a README
How-to guides
Manage wikis with CLI
View wiki history and revert
Filter or print wiki content
Follow wiki pages, get notifications
Create work item from wiki content
Add comments to wiki
Version, select, or un-publish a wiki
Update wiki pages offline
Manage wiki permissions (Security)
Migrate wiki extension pages
Reference
Basic Markdown guidance
Wiki Markdown guidance
Keyboard shortcuts to manage wiki pages
Default permissions (Security)
Data protection overview
Search
Get started with search
Functional code search
Functional work item search
Functional package search
Search organization settings
Install and configure search
Manage search indexing
FAQs
Navigation
Web portal navigation
Open a service, page, or setting
Add an artifact or team artifacts
Use breadcrumbs, selectors, and directories
Open another project or repo
Work with favorites
Filter basics
Keyboard shortcuts
Manage or enable features
Reference
Go mobile
Glossary
Feedback
About feedback
Test & Feedback extension
Request stakeholder feedback
Provide stakeholder feedback
Get insights from tests
Install the extension
Test in Connected mode
Test in Standalone mode
Explore work items
Add to existing bugs
Provide feedback without a request
Track stakeholder feedback requests
Microsoft Feedback client
Request feedback
Provide feedback
Track feedback requests
Set feedback permissions (Security)
Enable remote audio capture
Change the audio device or annotation tool
REST API Reference
Search
Wikis
Fetch Wiki search results
Resources
Get Started
Notifications
Manage projects
Settings & Usage
Azure Boards
Analytics & reporting
Set user preferences
11/17/2022 • 2 minutes to read • Edit Online
Azure DevOps Ser vices | Azure DevOps Ser ver 2022 - Azure DevOps Ser ver 2019 | TFS 2018
You can set user preferences on the user profile page in Azure DevOps. Changes can include the picture, display
name, preferred email, and UI theme. These settings only apply to Azure DevOps.
TIP
To change the settings for your work or school account, see Change work or school account settings in the My
Account portal.
You can't change the UI theme if you're using Internet Explorer. For more information about the browsers we support,
see Azure DevOps client compatibility.
Language settings apply only to your profile page.
See the following articles for setting other user preferences:

Change time and locale: Change the preferred language, date and time patterns, and time zone.
Manage personal notifications: Add or review subscriptions to event changes.
Refresh or re-evaluate your permissions: Use to refresh permissions and make any recent changes take
effect.
Manage preview features: Enable or disable a preview feature for your user account.
NOTE
The images you see from your web portal may differ from the images you see in this article. These differences result from
updates made to Azure DevOps or enabled preview features. We've enabled the New account manager page feature. The
basic functionality available to you remains the same unless explicitly mentioned.
On the Azure DevOps user profile page, you can change the user picture, display name, preferred email,
language, date and time pattern, time zone, and other user interface preferences.
See the following articles for setting more user preferences:
Use personal access tokens
Use SSH key authentication
Manage personal notifications
NOTE
On your user profile page, you can change your picture, display name, preferred email, language, date and time
pattern, time zone, and other user interface preferences.
Other tools for setting your Azure DevOps preferences include Notifications to add or review subscriptions to
event changes.
Set preferences
1. From the home page, select User settings , and then select Profile .
2. From the Profile page, you can change the profile picture, display name, contact information, and
country/region. Select Save . Select the Time and Locale tab to change more settings, like language,
date and time pattern, time zone, and UI theme.
1. To change the user preferences, open the user profile menu, and then select My profile .
2. From the General tab, you can change the following information:
Profile picture
Display name
Preferred email
Whether borders appear for fields on work item forms.
3. From the Locale tab, you can change the preferred language, date and time pattern, and time zone.
4. To change the UI theme, go back to the profile menu and select Theme . Choose between Dark and
Light .
5. Select Save .
1. To change the user preferences, open the user profile menu.
2. Choose Edit profile .

3. From the About page, you can change the user profile picture, display name, contact information, and
country.
4. From the Preferences page, you can change the following information:
preferred language
date and time pattern
time zone
UI theme
User profile settings are updated.
Related articles
Time zone settings and usage
Usage
Set favorites
Personal access tokens
You can set user preferences on the user profile page in Azure DevOps. Changes can include the picture, display
name, preferred email, and UI theme. These settings only apply to Azure DevOps.
TIP
To change the settings for your work or school account, see Change work or school account settings in the My
Account portal.
You can't change the UI theme if you're using Internet Explorer. For more information about the browsers we support,
see Azure DevOps client compatibility.
Language settings apply only to your profile page.
See the following articles for setting other user preferences:

Change time and locale: Change the preferred language, date and time patterns, and time zone.
Manage personal notifications: Add or review subscriptions to event changes.
Refresh or re-evaluate your permissions: Use to refresh permissions and make any recent changes take
effect.
Manage preview features: Enable or disable a preview feature for your user account.
NOTE
On the Azure DevOps user profile page, you can change the user picture, display name, preferred email,
language, date and time pattern, time zone, and other user interface preferences.
See the following articles for setting more user preferences:
Use personal access tokens
Use SSH key authentication
NOTE
On your user profile page, you can change your picture, display name, preferred email, language, date and time
pattern, time zone, and other user interface preferences.
Other tools for setting your Azure DevOps preferences include Notifications to add or review subscriptions to
event changes.
Set preferences
1. From the home page, select User settings , and then select Profile .
2. From the Profile page, you can change the profile picture, display name, contact information, and
country/region. Select Save . Select the Time and Locale tab to change more settings, like language,
date and time pattern, time zone, and UI theme.
1. To change the user preferences, open the user profile menu, and then select My profile .
2. From the General tab, you can change the following information:
Profile picture
Display name
Preferred email
Whether borders appear for fields on work item forms.
3. From the Locale tab, you can change the preferred language, date and time pattern, and time zone.
4. To change the UI theme, go back to the profile menu and select Theme . Choose between Dark and
Light .
5. Select Save .
1. To change the user preferences, open the user profile menu.
2. Choose Edit profile .

3. From the About page, you can change the user profile picture, display name, contact information, and
country.
4. From the Preferences page, you can change the following information:
preferred language
date and time pattern
time zone
UI theme
User profile settings are updated.
Related articles
Time zone settings and usage
Usage
Set favorites
Personal access tokens
Default permissions quick reference for Azure
DevOps
To use Azure DevOps features, users must be added to a security group with the appropriate permissions and
granted access to the web portal. Limitations to select features are based on the access level and security group
to which a user is assigned. The Basic access level and higher supports full access to most Azure DevOps
Services, except for Azure Test Plans. Stakeholder access level provides partial support to Azure Boards and
Azure Pipelines. To learn more about access levels, see About access levels and Stakeholder access quick
reference.
Assign users to a security group

The most common built-in security groups—Readers , Contributors , and Project Administrators — and
team administrator role grant permissions to specific features.
In general, use the following guidance when assigning users to a security group:
Add to the Contributors security group full-time workers who contribute to the code base or manage
projects.
Add to the Project Administrators security group users tasked with managing project resources. I
Add to the Project Collection Administrators security group users tasked with managing organization or
collection resources.
To learn more about administrative tasks see About user, team, project, and organization-level settings. For a
complete reference of all built-in groups and permissions, see Permissions and groups. For information about
access levels, see About access levels.
In the tables provided in this article, a ✔
️ (checkmark) indicates that the corresponding access level or security
group has access to a feature by default.
To assign or change an access level, see Add users and assign licenses. If you need to grant specific users select
permissions, you can do so.
Azure Boards
You can plan and track work from the web portal Boards hub, and using Visual Studio, Excel, and other clients.
For an overview of work tracking features, see About Agile tools. To change permissions, see Set permissions
and access for work tracking. In addition to the permissions set at the project level via the built-in groups, you
can set permissions for the following objects: area and iteration paths and individual queries and query folders.
Work tracking
You can plan and track work from the web portal Work hub, and using Eclipse, Visual Studio, Excel, Project, and
other clients.
NOTE
Team administrators can configure settings for their team's tools. Organization owners and members of the Project
Administrators group can configure settings for all teams. To be added as an administrator, see Add team
administrators or Change project-level permissions.
Access to the following tasks are controlled by each user's access level or by permission assignments. Members
of the Readers, Contributors, or Project Administrators group are assumed to have Basic access or greater.
General work item permissions
You can use work items to track anything you need to track. To learn more, see Understand how work items are
used to track issues, tasks, and epics.
NOTE
You can change the work item type or move work items to another project within a project collection. These features
require that the data warehouse is disabled. With the data warehouse disabled, you can use the Analytics Service to
support your reporting needs. To learn more about disabling the data warehouse, see Disable the data warehouse and
cube.
Task or permission
Readers
Contributors
Project admins
View work items in this node (Area Path permission)
️
✔
️
✔
️
✔
Edit work items in this node (Area Path permission)
️
✔
️
✔
Create tag definition
️
✔
️
✔
Change work item type (Project-level permission)
️
✔
️
✔
Move work items out of this project (Project-level permission)
️
✔
️
✔
Email work items
️
✔
️
✔
️
✔
Apply a work item template
️
✔
️
✔
Delete and restore work items (Project-level permission) (able to restore from the Recycle bin)
️
✔
️
✔
Permanently delete work items (Project-level permission)
️
✔
Provide feedback (through the Microsoft Feedback client)
️
✔
️
✔
Request feedback
️
✔
️
✔
NOTE
Work items are subject to rules applied to them. Conditional rules based on user or group membership are cached for
your web browser. If you find yourself restricted to update a work item, you may have encountered one of these rules. If
you believe you've encountered an issue that doesn't apply to you, see Work item form IndexDB caching issues. To learn
more about conditional rules, see Rules and rule evaluation.
Boards
You use Boards to implement Kanban methods. Boards present work items as cards and support quick status
updates through drag-and-drop.
Task
Readers
Contributors
Team admins
Project admins
View boards and open work items
️
✔
️
✔
️
✔
Add work items to a board; update status through drag-and-drop
️
✔
️
✔
Reorder work items or reparent child items through drag-and-drop; update a field on a card
️
✔
️
✔
Add work items to a board; update status, reorder, or reparent child items through drag-and-drop; update a field
on a card
️
✔
️
✔
Add child items to a checklist
️
✔
️
✔
Assign to a sprint (from card field)
️
✔
️
✔
Configure board settings
️
✔
Backlogs features access
Backlogs display work items as lists. A product backlog represents your project plan and a repository of all the
information you need to track and share with your team. Portfolio backlogs allow you to group and organize
your backlog into a hierarchy.
Task
Readers
Contributors
Team admins
Project admins
View backlogs and open work items
️
✔
️
✔
️
✔
Add work items to a backlog
️
✔
️
✔
Use bulk edit features
️
✔
️
✔
Add child items to a backlog item; prioritize or reorder a backlog; parent items using the Mapping pane; Assign
items to a sprint using the Planning pane
️
✔
️
✔
Add child items to a backlog item; prioritize or reorder a backlog; parent items using the Mapping pane; Assign
items to a sprint using drag-and-drop
️
✔
️
✔
Configure team settings, backlog levels, show bugs, work days off
️
✔
Sprints
You use sprint tools to implement Scrum methods. The Sprints set of tools provide filtered views of work items
that a team has assigned to specific iteration paths or sprints.
Task
Readers
Contributors
Team admins Project admins
View sprint backlogs, taskboards, and open work items
️
✔
️
✔
️
✔
Add work items to a sprint backlog or taskboard
️
✔
️
✔
Prioritize/reorder a sprint backlog or taskboard; add child items to a backlog item; reassign items to a sprint
using the Planning pane
️
✔
️
✔
View team capacity and work details
️
✔
️
✔
Set team capacity
️
✔
️
✔
Use bulk edit features
️
✔
️
✔
Define team sprints
️
✔
Queries
Queries are filtered lists of work items based on criteria that you define by using a query editor. Adhoc searches
are powered by a semantic search engine.
Task
Readers
Contributors
Project admins
View and run managed queries, view query charts
️
✔
️
✔
️
✔
Create and save managed My queries, query charts
️
✔
️
✔
Create, delete, and save Shared queries, charts, folders
️
✔
Delivery plans
Delivery plans display work items as cards against a calendar view. This format can be an effective
communication tool with managers, partners, and stakeholders for a team.
Task
Readers
Contributors
Team admins
Project admins
View delivery plans
️
✔
️
✔
️
✔
Create, edit, or delete a delivery plan, Contributors can only edit or delete plans that they create
️
✔
️
✔
Manage permissions for a delivery plan, Contributors can only manage permissions for plans that they create
️
✔
️
✔
Azure Repos
You can manage your source code from the web portal Repos hub, or using Xcode, Eclipse, IntelliJ, Android
Studio, Visual Studio, or Visual Studio Code.
Stakeholders for private projects have no access to Repos . Stakeholders for public projects have the same
access to Repos as Contributors .
Code: Source control

You can connect to your code from the web portal Code hub, or using Xcode, Eclipse, IntelliJ, Android Studio,
Visual Studio, or Visual Studio Code. Stakeholders for private projects have no access to Code .
Git
You can use Git repositories to host and collaborate on your source code. For an overview of code features and
functions.
Permission
Readers
Contributors
Build Admins
Project Admins
Read (clone, fetch, and explore the contents of a repository); also, can create, comment on, vote, and
Contribute to pull requests
️
✔
️
✔
️
✔
️
✔
Contribute , Create branches , Create tags , and Manage notes
️
✔
️
✔
️
✔
Create repositor y , Delete repositor y , and Rename repositor y
️
✔
Edit policies , Manage permissions , Remove others' locks
️
✔
Force push (rewrite history, delete branches and tags)
️
✔
Bypass policies when completing pull requests
(not set for any security group)
Bypass policies when completing pull requests , Bypass policies when pushing , Force push (rewrite
history, delete branches and tags)
(not set for any security group)
TFVC
Team Foundation Version Control (TFVC) provides a centralized version control system to manage your source
control.
NOTE
Tasks such as create, delete, or rename a TFVC repository are not supported. Once a TFVC repository is created you can't
delete it. Also, you can only have one TFVC repository per project. This is different from Git repositories which allow for
adding, renaming, and deleting multiple repositories.
Permission
Readers
Contributors
Build Admins
Project Admins
Check in , Label , Lock , Merge , Pend a change in a ser ver workspace , Read
Read only
️
✔
️
✔
️
✔
Administer labels , Manage branches , Manage permissions , Revise other users' changes , Undo other
users' changes , Unlock other users' changes
️
✔
Azure Pipelines
You can define and manage your builds and releases from the web portal Pipelines hub. For an overview of
pipelines features and functions, see Continuous integration on any platform.
P RO JEC T REL EA SE
TA SK REA DERS C O N T RIB UTO RS B UIL D A DM IN S A DM IN S A DM IN S
View release ️
✔ ️
✔ ️
✔ ️
✔ ️
✔
pipelines
Define builds ️
✔ ️
✔ ️
✔
with continuous
integration
Define releases ️
✔ ️
✔ ️
✔
and manage
deployments
Approve releases ️
✔ ️
✔ ️
✔ ️
✔
Azure Artifacts ️
✔ ️
✔ ️
✔
(5 users free)
Queue builds, ️
✔ ️
✔ ️
✔
edit build quality
Manage build ️
✔ ️
✔
queues and build
qualities
Manage build ️
✔ ️
✔ ️
✔
retention
policies, delete
and destroy
builds
Administer build ️
✔ ️
✔
permissions
Manage release ️
✔ ️
✔
permissions
Create and edit ️

✔ ️
✔ ️
✔ ️
✔
task groups
Manage task ️
✔ ️
✔ ️
✔
group
permissions
Can view library ️

✔ ️
✔ ️
✔ ️
✔ ️
✔
items such as
variable groups
Use and manage ️

✔ ️
✔ ️
✔
library items
such as variable
groups
Build
Task
Readers
Contributors
Build admins
Project admins
View builds
️
✔
️
✔
️
✔
️
✔
View build pipeline
️
✔
️
✔
️
✔
️
✔
Administer build permissions
️
✔
️
✔
Delete or Edit build pipeline
️
✔
️
✔
️
✔
Delete or Destroy builds
️
✔
️
✔
Edit build quality
️
✔
️
✔
️
✔
Manage build qualities
️
✔
️
✔
Manage build queue
️
✔
️
✔
Override check-in validation by build
️
✔
Queue builds
️
✔
️
✔
️
✔
Retain indefinitely
️
✔
️
✔
️
✔
️
✔
Stop builds
️
✔
️
✔
Update build information
️
✔
Release
Task
Stakeholders
Readers
Contributors
Project Admins
Release
Admins
Approve releases
️
✔
️
✔
️
✔
️
✔
View releases
️
✔
️
✔
️
✔
️
✔
️
✔
View release pipeline
️
✔
️
✔
️
✔
️
✔
Administer release permissions
️
✔
️
✔
Delete release pipeline or release stage
️
✔
️
✔
️
✔
Delete releases
️
✔
️
✔
️
✔
Edit release pipeline
️
✔
️
✔
Edit release stage
️
✔
️
✔
️
✔
Manage deployments
️
✔
️
✔
Manage release approvers
️
✔
️
✔
️
✔
Manage releases
️
✔
️
✔
Task groups
You use task groups to encapsulate a sequence of tasks already defined in a build or a release pipeline into a
single reusable task. Task group permissions follow a hierarchical model. You can set defaults for all permissions
at the project-level and over-write on an individual task group pipeline. You define and manage task groups in
the Task groups tab in Azure Pipelines .
Administer task ️
✔ ️
✔ ️
✔
group
permissions
Delete task ️
✔ ️
✔ ️
✔
group
Edit task group ️

✔ ️
✔ ️
✔
Build and Release

You can define and manage your builds and releases from the web portal, Build and Release . For an overview
of pipelines features and functions, see Continuous integration on any platform. From the web portal, you can
set permissions for all or individual builds and releases. See Set build and release permissions.
Build
Task
Readers
Contributors
Build
Admins
Project Admins
View builds
️
✔
️
✔
️
✔
️
✔
View build definition
️
✔
️
✔
️
✔
️
✔
Administer build permissions
️
✔
️
✔
Delete or Edit build definitions
️
✔
️
✔
️
✔
Delete or Destroy builds
️
✔
️
✔
Edit build quality
️
✔
️
✔
️
✔
Manage build qualities
️
✔
️
✔
Manage build queue
️
✔
️
✔
Override check-in validation by build
️
✔
Queue builds
️
✔
️
✔
️
✔
Retain indefinitely
️
✔
️
✔
Stop builds
️
✔
️
✔
Update build information
️
✔
Release
Task
Readers
Contributors
Project Admins
Release
Admins
Approve releases
️
✔
️
✔
️
✔
View releases
️
✔
️
✔
️
✔
️
✔
View release definition
️
✔
️
✔
️
✔
️
✔
Administer release permissions
️
✔
️
✔
Delete release definition or release stage
️
✔
️
✔
️
✔
Delete releases
️
✔
️
✔
️
✔
Edit release definition
️
✔
️
✔
Edit release stage
️
✔
️
✔
️
✔
Manage deployments
️
✔
️
✔
Manage release approvers
️
✔
️
✔
️
✔
Manage releases
️
✔
️
✔
Azure Test Plans

Users granted Basic + Test Plans or Visual Studio Enterprise access level can define and manage manual
tests from the web portal. For an overview of manual test features and functions, see Testing overview. You set
several test permissions at the project level from Project Settings>Permissions .
Test
Users granted Visual Studio Enterprise or Advanced access level can define and manage manual tests from
the web portal. For an overview of manual test features and functions, see Testing overview. You set several test
permissions at the project level from Project Settings>Permissions .
Permission
Level
Readers
Contributors
Project Admins
View test runs
Project-level
️
✔
️
✔
️
✔
Create test runs
Delete test runs
Project-level
️
✔
️
✔
Manage test configurations
Manage test environments
Project-level
️
✔
️
✔
Create tag definition
Delete and restore work items
Project-level
️
✔
️
✔
Permanently delete work items
Project-level
️
✔
View work items in this node
Area Path
️
✔
️
✔
️
✔
Edit work items in this node
Manage test plans
Manage test suites
Area Path
️
✔
️
✔
NOTE
The Change work item type permission doesn't apply to test-specific work items. Even if you choose this feature from
the work item form, changing the work item type is disallowed.
Azure Artifacts
You can manage feeds from the web portal, Ar tifacts . Users granted Stakeholder or Basic access, or higher can
access Azure Artifacts features. To set permissions, see Secure feeds using permissions.
You can manage feeds from the web portal, Ar tifacts . Users granted Basic access or higher can access Azure
Artifacts features. Users granted Stakeholder access have no access to Azure Artifacts. To set permissions, see
Secure feeds using permissions.
Package management
You can manage feeds from the web portal, Build and release > Packages . Users granted Basic access or
higher can access Package management features. Users granted Stakeholder access have no access. To set
permissions, see Secure feeds using permissions.
Feeds have four permission roles: Readers, Collaborators, Contributors, and Owners. Owners can add user
accounts or security groups to any role.
P ERM ISSIO N REA DER C O L L A B O RATO R C O N T RIB UTO R O W N ER
List, install, and ️

✔ ️
✔ ️
✔ ️
✔
restore packages
Push packages ️
✔ ️
✔
Unlist/deprecate ️
✔ ️
✔
packages
Delete/unpublish ️
✔
package
Promote a package ️
✔ ️
✔
to a view
Add/remove ️
✔
upstream sources
Save packages from ️

✔ ️
✔ ️
✔
upstream sources
Edit feed permissions ️

✔
By default, the Project Collection Build Service is a Contributor and your project team is a Reader.
NOTE
To access a feed in a different organization, a user must be given access to the project hosting that feed.
Feeds have three permission roles: Readers, Contributors, and Owners. Owners can add user accounts or
security groups -to any role.
P ERM ISSIO N REA DER C O N T RIB UTO R O W N ER
List and restore/install ️

✔ ️
✔ ️
✔
packages
Push packages ️
✔ ️
✔
Unlist/deprecate packages ️
✔ ️
✔
Delete/unpublish package ️
✔
Edit feed permissions ️

✔
P ERM ISSIO N REA DER C O N T RIB UTO R O W N ER
Rename and delete feed ️

✔
By default, the Project Collection Build Service is a Contributor and your project team is a Reader.
NOTE
To access a feed in a different organization, a user must be given access to the project hosting that feed.
Notifications, alerts, and team collaboration tools

To manage notifications, see Manage personal notifications and Manage team notifications.
NOTE
There are no UI permissions associated with managing notifications. Instead, you can manage them using the TFSSecurity
command line tool.
Task
Readers
Contributors
Team admins
Project admins Project Collection admins
View the project page, navigate using the project page

️
✔
️
✔
️
✔
️
✔
Edit the project page
️
✔
Set personal notifications or alerts
️
✔
️
✔
️
✔
Set team notifications or alerts
️
✔
️
✔
Set project-level notifications or alerts
️
✔
View Project READMEs
️
✔
️
✔
️
✔
️
✔
View Project wikis or code wikis
️
✔
️
✔
️
✔
️
✔
Provision or create a project wiki
️
✔
️
✔
️
✔
Publish code as a wiki
️
✔
️
✔
️
✔
Request feedback
️
✔
️
✔
️
✔
Provide feedback
️
✔
️
✔
️
✔
️
✔
Search across projects, organizations, collections
️
✔
️
✔
️
✔
️
✔
Dashboards, charts, reports, and widgets

You can define and manage team and project dashboards from the web portal, Dashboards . For an overview
of dashboard and chart features, see Dashboards. You can set individual dashboard permissions to grant or
restrict the ability to edit or delete dashboards.
Users granted Stakeholder access to private projects can't view or create query charts. Stakeholder access to
public projects can view and create query charts.
You can define and manage team dashboards from the web portal, Dashboards . For an overview of dashboard
and chart features, see Dashboards. You set dashboard permissions at the team level from the team dashboard
page.
Task
Readers
Contributors
Team admins
Project admins
View team and project dashboards

️
✔
️
✔
️
✔
️
✔
View team dashboards

️
✔
️
✔
️
✔
Add and configure project dashboards

️
✔
️
✔
Add and configure team dashboards

️
✔
️
✔
️
✔
Power BI Integration and Analytics views

From the web portal Analytics views , you can create and manage Analytics views. An Analytics view provides
a simplified way to specify the filter criteria for a Power BI report based on the Analytics Service data store. The
Analytics Service is the reporting platform for Azure DevOps. To learn more, see What is the Analytics Service?.
You set permissions for the service at the project level, and for shared Analytics views at the object level. Users
with Stakeholder access have no access to view or edit Analytics views.
Task
Readers
Contributors
Project admins
View Analytics
️
✔
️
✔
️
✔
View a shared Analytics view
️
✔
️
✔
Add a private or shared Analytics view
️
✔
️
✔
Edit and delete shared Analytics views
️
✔
Related articles
Add users to a project or team
Security and permission management tools
Permissions and groups reference
About access levels
Troubleshoot permissions
Connect to a project in Azure DevOps
Learn how to connect to a project to share code, build apps, track work, and collaborate with team members.
You can use any of the following clients:
Web portal
Visual Studio or Team Explorer
Eclipse/Team Explorer Everywhere
Android Studio with the Azure DevOps Services Plugin for Android Studio
IntelliJ with the Azure DevOps Services Plugin for IntelliJ
Visual Studio Code
A project defines a process and data storage in which you manage your software projects from planning to
deployment. When you connect to a project, you connect to an organization or project collection. One or more
projects may be defined within a collection. There must be at least one project. For more information, see About
projects and scaling your organization.
Prerequisites
If you don't have a project yet, create one.
If you need to add a team, see Add teams. If you don't have access to the project, get invited to the team.
From each of these clients, you can switch context to a different project and connect as a different user. If
you work remotely, configure your client to connect to an Azure DevOps Proxy Server.
To get started with a code base, set up Git or set up TFVC.
Connect from the web portal

1. If you're not a member of a security group, ask your Project Administrator to add you.
2. Open a browser and enter a URL that uses the following form:
https://dev.azure.com/OrganizationName/ProjectName
http://ServerName/DefaultCollection/ProjectName
For example, to connect to the server named FabrikamPrime , type:

http://FabrikamPrime/DefaultCollection .
http://ServerName:8080/tfs/DefaultCollection/ProjectName
For example, to connect to the server named FabrikamPrime , type:

http://FabrikamPrime:8080/tfs/DefaultCollection .
The default Port is 8080. If you don't use default values, specify the port number and directory for your
server.
3. When you access the server for the first time, a Windows Identity dialog box appears. Enter your
credentials and choose OK .
TIP
If you select Remember me , you won't have to enter your credentials the next time you connect.
4. Choose your project, team, or page of interest.

From the project summary page, hover over a service and then choose the page you want. To choose
another project, choose Azure DevOps .
From the project summary page, hover over a service and then choose the page you want. To choose
another project, choose the Azure DevOps logo.
To learn more about each page and the tasks you can do, see Web portal navigation.
Sign in with different credentials

1. Open your profile menu and choose Sign out .
2. Choose Sign in and enter your credentials.

Open the web portal from Team Explorer
Open the web portal from the home page.
Connect from Visual Studio or Team Explorer
If you haven't already, download and install a version of Visual Studio.
If you're not a member of an Azure DevOps security group, get added to one. Check with a team member. You'll
need the names of the server, project collection, and project to connect to.
Visual Studio 2019

Visual Studio 2017
Visual Studio 2015
Visual Studio 2019

1. Select the Manage Connections button in Team Explorer to open the Connect page. Choose Connect
to a Project to select a project to connect to.
Connect to a Project shows the projects you can connect to, along with the repos in those projects.
2. Select Add Azure DevOps Ser ver to connect to a project in Azure DevOps Services. Enter the URL to
your server and select Add .
3. Select a project from the list and select Connect .

Change sign-in credentials
Visual Studio 2019
Visual Studio 2017
Visual Studio 2015
Visual Studio 2019

1. From Connect , choose the Connect to a Project link to sign in with different credentials.
2. Select a different user or select Add an account to access a project using different credentials.
3. Sign in using an account that is associated with an Azure DevOps project, either a valid Microsoft account
or GitHub account.
Use different Visual Studio credentials
You can run Visual Studio with credentials different from your current Windows user account. Find devenv.exe
under the Program Files (86) folder for your version of Visual Studio.
Select Shift and right-click devenv.exe, then select Run as different user .
User accounts and licensing for Visual Studio

To connect to a project, you need your user account added to the project. The Organization owner for Azure
DevOps Services or a member of the Project Administrators group usually adds user accounts. To learn
more, see Add organization users and manage access or Add or remove users or groups, manage security
groups.
Azure DevOps Services provides access to the first five account users free. After that, you need to pay for more
users.
For on-premises TFS, each user account must have a TFS client access license (CAL). All Visual Studio
subscriptions and paid Azure DevOps Services users include a TFS CAL. Find out more about licensing from the
Team Foundation Server pricing page.
You can also provide access to Stakeholders in your organization who have limited access to select features as
described in Work as a Stakeholder.
Configure Visual Studio to connect to Azure DevOps Proxy Server
If your remote team uses a Azure DevOps Proxy Server to cache files, you can configure Visual Studio to connect
through that proxy server and download files under Team Foundation version control.
1. First, make sure that you've connected to Azure DevOps Server as described in the previous section.
2. From the Visual Studio Tools menu, select Options , then select Source Control > Plug-in Selection .
Select Visual Studio Team Foundation Ser ver .
3. For Visual Studio Team Foundation Ser ver , enter the name and port number for the Azure DevOps
Proxy Server. Select Use SSL encr yption (https) to connect .
Make sure you specify the port number that your administrator assigned to TFS Proxy.
To associate a file type with a compare or merge tool, see Associate a file type with a file-comparison tool or
Associate a file type with a merge tool.
What other clients support connection to Azure DevOps?
Besides connecting through a web browser, Visual Studio, Eclipse, Excel, and Project you can connect to a project
from these clients:
Visual Studio Code
Visual Studio Community
Eclipse: Team Explorer Everywhere
Azure Test Plans (formerly Test Manager)
Microsoft Feedback Client
Requirements and client compatibility
Some tasks or features aren't available when you connect to a later version of Azure DevOps Server than your
client supports. For more information, see client compatibility.
Determine your platform version
See Look up your Azure DevOps platform and version.
Next steps
Learn more about how to:
Work in web portal
Work in Team Explorer
Work in Office Excel or Project
Troubleshoot connection
If all you need is a code repository and bug tracking solution, then start with the Get Started with Azure Repos
and Manage bugs.
To start planning and tracking work, see Get started with Agile tools to plan and track work.
Web portal navigation in Azure DevOps
The web portal for Azure DevOps is organized around a set of services as well as administrative pages and
several task specific features such as the search box. The service labels differ depending on whether you work
from Azure DevOps Services or Azure DevOps on premises and its version.
IMPORTANT
To view the content available for your platform, make sure that you select the correct version of this article from the
version selector which is located above the table of contents. Feature support differs depending on whether you are
working from Azure DevOps Services or an on-premises version of Azure DevOps Server.
To learn which on-premises version you are using, see Look up your Azure DevOps platform and version
Each service provides you with one or more pages which support a number of features and functional tasks.
Within a page, you may then have a choice of options to select a specific artifact or add an artifact.
The web portal for Azure DevOps Server is organized around a set of services—such as, Over view , Boards ,
Repos , Pipelines , Test Plans , and Ar tifacts — as well as administrative pages and several task-specific
features such as the search box. Each service provides you with one or more pages which support a number of
features and functional tasks. Within a page, you may then have a choice of options to select a specific artifact or
add an artifact.
The web portal for Team Foundation Server is organized around a set of applications—such as, Dashboards ,
Code , Work , Build and Release —as well as administrative pages and several task-specific features such as
the search box. Each service provides you with one or more pages which support a number of features and
functional tasks. Within a page, you may then have a choice of options to select a specific artifact or add an
artifact.
Here's what you need to know to get up and running using the web portal.
Open a ser vice, page, or settings : use to switch to a different service or functional area
Add an ar tifact or team : use to quickly add a work item, Git repo, build or release pipelines, or a new team
Open another project or repo : use to switch to a different project or access work items and pull requests
defined in different projects, or items you've favorited
Open team ar tifacts, use breadcrumbs, selectors and directories : use to navigate within a service, to
open other artifacts, or return to a root function
Work with favorites : favorite artifacts to support quick navigation
Search box : use to find code, work items, or wiki content
Your profile menu : use to set personal preferences, notifications, and enable preview features
Settings : use to add teams, manage security, and configure other project and organization level resources.
Open another project or repo, or switch to a different team : use to switch to a different project or
browse teams
Work across projects : use to quickly open work assigned to you, your active pull requests, or items you've
favorited
Open team ar tifacts, use breadcrumbs & selectors : use to navigate within a service, to open other
artifacts or return to a root function
Settings : use to add teams, manage security, and configure other project and organization-level resources.
NOTE
Only those services that are enabled will appear in the user interface. For example, if Boards is disabled, then Boards or
Work and all pages associated with that service won't appear. To enable or disable a service, see Turn an Azure DevOps
service on or off.
You select services —such as Boards , Repos , and Pipelines — from the sidebar and pages within those
services.
You select a service—such as Code , Work , and Build and Release —from the horizontal bar and pages within
those services.
Now that you have an understanding of how the user interface is structured, it's time to get started using it. As
you can see, there are a lot of features and functionality.
If all you need is a code repository and bug tracking solution, then start with Get started with Git and Manage
bugs.
To start planning and tracking work, see About Agile tools.
Connect to the web portal, user accounts, and licensing

You connect to the web portal through a supported web browser —such as the latest versions of Edge, Chrome,
Safari, or Firefox. Only users who have been added to a project can connect. This is typically done by the
organization owner.
Five account users are free as are Visual Studio subscribers and stakeholders. After that, you need to pay for
more users. Find out more about licensing from Azure DevOps pricing.
Limited access is available to an unlimited number of stakeholders for free. For details, see Work as a
Stakeholder.
You connect to the web portal through a supported web browser—such as the latest versions of Edge, Chrome,
Safari, or Firefox. Only users who have been added to a project can connect. This is typically done by a member
of the Project Administrators group.
Stakeholder. Most regular contributors must have a TFS client access license (CAL). All Visual Studio
subscriptions include a TFS CAL. Find out more about licensing from TFS pricing.
Refresh the web portal

If data doesn't appear as expected, the first thing to try is to refresh your web browser. Refreshing your client
updates the local cache with changes that were made in another client or the server. To refresh the page or
object you're currently viewing, refresh the page or choose the Refresh icon if available.
To avoid potential errors, you should refresh your client application under the following circumstances:
Process changes are made
Work item type definitions are added, removed, renamed, or updated
Area or iteration paths are added, removed, renamed, or updated
Users are added to or removed from security groups or permissions are updated
A team member adds a new shared query or changes the name of a shared query
A build definition is added or deleted
A team or project is added or deleted
Differences between the web portal and Visual Studio

Although you can access source code, work items, and builds from both clients, some task specific tools are only
supported in the web browser or an IDE but not in both. Supported tasks differ depending on whether you
connect to a Git or TFVC repository from Team Explorer.
Web por tal

Visual Studio
Product backlog, Portfolio backlogs, Sprint backlogs, Taskboards, Capacity planning

Kanban boards
Dashboards, Widgets, Charts
Request feedback
Web-based Test Management
Administration pages to administer accounts, team projects, and teams
Git: Changes, Branches, Pull Requests, Sync, Work Items, Builds
TFVC: My Work, Pending Changes | Source Control Explorer, Work Items | Builds
Greater integration with work items and Office integration clients. You can open a work item or query result
in an office supported client.
NOTE
Visual Studio 2019 version 16.8 and later versions provide a new Git menu for managing the Git workflow with less
context switching than Team Explorer. Procedures provided in this article under the Visual Studio tab provide information
for using the Git experience as well as Team Explorer. To learn more, see Side-by-side comparison of Git and Team Explorer.
Resources
Manage projects
Project & Organizational Settings
You can quickly find work items, code files, wiki pages, or packages based on a keyword, wildcards, and other
supported search filters with the search function.
Take an at-a-glance look at all of the search features further in this article.
Prerequisites
Every project member can use the search functions, including project members granted Stakeholder, Basic,
and higher levels of access.
When searching across the organization or collection, only results for which a project member has access are
listed.
Stakeholder wiki search results are limited to provisioned wikis. Because published wikis require access to
regular repositories, which Stakeholders don't have access to, results for published wikis don't appear in the
search results. Similarly, Code search results don't appear for Stakeholders.
IMPORTANT
For Code search, a Collection Administrator must Install and configure search.
Start your search with a keyword

Start your search using a keyword. You can then apply other options, as needed, to broaden or narrow your
search results.
If you get no results matching the input, try removing filters and retry the search. Broadening the search and
after you view the search results, you can apply appropriate filters again and search again for relevant
results.
Check for the spelling of your search terms. Currently Work item search doesn't support ignoring of users'
spelling mistakes.
If there are lots of hits when you're using a wildcard search, such as when you're using a simple wildcard
search string, you may see a message that no matching files are found. In this case, narrow your search to
reduce the number of matches. Specify more characters of the word or words that you want to find, or add a
condition or filter to limit the number of possible matches.
Searches aren't case-sensitive.
Search features, usage, and examples

The following features apply to all searches, including work items, code, wikis, and packages.
The following features apply to all searches, including work items, code, and packages.
Search feature
Usage
Example
Keyword
Search based on one or more keywords.
validate finds instances that contain the word validate.
Exact match
Search based on an exact match, enclosed in double-quotes.
"Client not found" finds instances that contain the exact phrase match Client not found.
Wildcard
Add wildcard characters, * and ? , to keywords to extend the search criteria.
Add * at the end of a keyword to find items that start with the keyword.
Add ? in the middle to represent any alphanumeric character.
Use wildcard characters anywhere in your search string except as a prefix. You can use prefix wildcards with
the other search filter functions.
You can use more than one wildcard to match more than one character.
alpha?version finds instances of alpha1version and alphaXversion.
Browser* finds instances of BrowserEdge, BrowserIE, and BrowserFirefox.
CodeSenseHttp* finds files containing words that start with CodeSenseHttp, such
as CodeSenseHttpClient and CodeSenseHttpClientTest.
Boolean operators
Find two or more keywords using Boolean operators: AND , OR , and NOT (must be uppercase).
Add parenthesis to clauses to support logical groupings.
Because AND is the default operator, an entry of two keywords with no operator is the same as an AND
search.
Validate AND revisit finds files that contain both the words validate and revisit.
Validate OR revisit finds files that contain either of the words validate or revisit.
Validate NOT revisit finds files that contain the word validate but not the word revisit.
(Validate NOT revisit) OR "release delayed" finds files that contain the word validate but not the
word revisit or files that contain the phrase release delayed.
Proximity
Search for files based on vicinity using proximity operators: NEAR, BEFORE, and AFTER (must be uppercase).
By default, proximity search looks for terms within five tokens distance.
term1 BEFORE term2 returns all files where term1 occurs BEFORE term2 within a distance of five tokens
between them.
term1 AFTER term2 returns the same results as term2 BEFORE term1.
term1 NEAR term2 returns all files where term1 is within five token distance from term2 in any direction.
term1 NEAR term2 returns the same results as term1 BEFORE term2 OR term2 BEFORE term1 .
Special characters
Escape the special characters ( , ) , [ , ] , : , * , and ? by enclosing them in a phrase delimited with
double-quotes.
Include special characters in a search string, or search specifically for special characters, according to the
following rules:
CodeA23?R finds files containing words that start with CodeA23
Have any alphanumeric character next, and end with R. For example, CodeA234R and CodeA23QR.
Search for any special character that isn't a part of the query language.
"flatten()" finds the literal string flatten(). Search for a literal occurrence of the double-quote character " by
preceding it with the escape character \ and enclosing the search string in double-quotes.
"\"react-redux\"" finds the literal string "react-redux".
Search from a different page

You can search from any of the following pages:
The Projects page for the organization: starts a search across all projects.
The Project overview page: automatically applies a filter to search within the selected project.
The Boards page for a project: automatically displays recent work items and backlogs accessed by the user.
Azure Repos, Pipelines, Test Plans, or an Artifacts page for a project: automatically displays functional filters
for code searches.
The wiki page for a project: automatically go to a wiki page you recently opened.
TIP
Use the content type filter to access a page that you recently accessed.
For more information about searching and filtering in Azure Boards, see Filter backlogs, boards, and plans.
For more information about searching wikis, see Provisioned vs. published wiki.
TIP
No results found for ...
If there's a large number of hits when using a wildcard search, such as when using a very simple wildcard search string,
you may see a message that no matching files were found. In this case, narrow your search to reduce the number of
matches. For example, specify more characters of the word(s) you want to find, or add a condition or filter to limit the
number of possible matches.
Additional search functions
To search for various settings, users, projects, and more, see the following table for other types of search tasks
and corresponding actions.
Search task
Action
Find an organization setting

Go to your organization and select Organization settings .
Find a project setting

Go to your project and select Project settings .
Find a user setting

Go to your User settings page .
Find a user
Go to your organization and select Organization settings > Users , and then enter the name in the filter box.
Find an organization
Scroll through the left side of your screen, which lists all organizations.
Find a project
Go to your organization, and then enter the project name in the Filter projects box.
View file history and compare versions

Go to Repos > Files , highlight your file, and then select Histor y .
NOTE
When you search from the Organization settings page, your search results include both organization-level and
project-level settings.
Search re-index requirements

Search for Azure DevOps Server has the following limitation:
If you do a disaster recovery (DR) operation and move your server back to an earlier snapshot of your SQL
database, re-index all your collections.
Marketplace extensions
Code search - Extends search with fast, flexible, and precise search results across all your code. Required for
searching repositories.
Azure Paths Search - Adds a special search hub to Boards for searching within iterations and area paths
without having to create and maintain custom queries.
NOTE
Some extensions aren't supported features of Azure DevOps and therefore aren't supported by the product team. For
questions, suggestions, or issues you have when using these extensions, visit their corresponding extension page on the
Visual Studio Marketplace.
Next steps
Functional work item search or Functional code search or Functional artifact or package search
Related articles
Code search blog posts
Work item search blog posts
Learn how to open a wiki and provision a Git repo for your wiki.
Every team project can have a wiki. Use the wiki to share information with your team to understand and
contribute to your project.
Each team project wiki is powered by a Git repository in the back-end. When you create a team project, a Wiki
Git repo is not created by default. Provision a Git repository to store your wiki Markdown files, or publish
existing Markdown files from a Git repository to a wiki.
Git repo isn't created by default. Provision a Git repository to store your wiki Markdown files.
Prerequisites
You must have a team project. If you don't have a team project yet, create one in Azure DevOps.
You must have at least Basic access to create and modify a wiki.
You must have the permission Create Repositor y to publish code as wiki. By default, this permission is set
for members of the Project Administrators group.
Anyone who is a member of the Contributors security group can add or edit wiki pages. Anyone with access
to the team project, including stakeholders, can view the wiki.
You must have a team project. If you don't have a team project yet, create one on-premises.
Open the Wiki

Browser
Azure DevOps CLI
Connect to your project using a supported web browser and choose Wiki .
If you need to switch your team project, choose Azure DevOps to browse all team projects and teams.
Provision a wiki Git repository

Browser
Azure DevOps CLI
Provision a new Git repository that stores all your wiki pages and related artifacts. From the wiki landing page,
select Create Project wiki . (Even if you use TFVC for source control, you can create a wiki with a Git
repository.)
If you don't have access to create a Wiki Git repository or if you don't have access to any of the existing wikis,
the following message appears.
Your administrator can provision the Wiki Git repository or you can request that they elevate your permissions.
Stakeholders can't create a wiki, as they have no permissions to work in Repos or Code .
The Wiki Git repo is referred as TeamProjectName.wiki. For example, if your team project is 'foobar' then the
Wiki repo is labeled 'foobar.wiki'.
NOTE
If you want to provision more wikis, then you must publish code as a wiki. You can set up multiple wiki repos within a
single project.
How can I go to the Git repository?

The TeamProjectName.wiki doesn't appear in the drop-down menu of repositories from Repos or Code . It also
isn't in the list provided from the Project Settings > Repositories or Project Settings > Version Control
pages.
However, you can get to it from the following URL:
https://dev.azure.com/<OrgName>/<TeamProjectName>/_git/<WikiName>
https://<ServerName>/DefaultCollection/<TeamProjectName>/_git/<WikiName>
Choose Clone Wiki from the ellipsis near the wiki picker to access the Wiki URL.
The URL of the wiki Git repository is exposed. Copy and paste it into your web browser to access the underlying
Git repo.
Next steps
Add and edit wiki pages
About Wikis, READMEs, and Markdown
To support your team or contributors to your project, use Markdown to add rich formatting, tables, and images
to your team project. You can use Markdown format within a team project Wiki, content you add to a dashboard,
your team project README file, or other repository README file.
Wiki
Use your team project wiki to share information with other team members. When you provision a wiki from
scratch, a new Git repository stores your Markdown files, images, attachments, and sequence of pages. This wiki
supports collaborative editing of its content and structure.
NOTE
The built-in wiki is available with TFS 2018 and later versions. To download Azure DevOps Server, see Visual Studio
Downloads.
The following features are supported for the team project wiki.
Provision or create a wiki
Create a wiki for your team project
Publish code as wiki
Work with wiki content
View wiki page history and revert
Version, select, or unpublish a published wiki
Clone and update wiki content offline
Use Wiki keyboard shortcuts
Filter or print Wiki content 1
NOTE
The print feature may not be available from the Firefox web browser.
Format wiki content

Markdown format
HTML tags
Insert and resize images
Link to work items using #
Attach files
Mathematical notation and characters
Table of contents (TOC) for Wiki pages
The following features are supported for the team project wiki you create in the indicated TFS version or later
versions. To learn more, see Create a wiki for your team project and Add and edit wiki pages.
F EAT URE T F S VERSIO N
Markdown format TFS 2018
HTML tags TFS 2018
Insert and resize images TFS 2018
Link to work items using # TFS 2018
Attach files TFS 2018
Filter Wiki TOC TFS 2018
Mathematical notation and characters TFS 2018.2
Preview a Wiki page while editing TFS 2018.2
Print a Wiki page 1 TFS 2018.2
Wiki keyboard shortcuts TFS 2018.2
Publish existing Git repositories to a wiki

Many teams document their code using Markdown and check in these files along with the code. While Git
supports the maintenance and review of such documentation along with standard pull requests, such files
present a few challenges to consumers of the content.
Readers must often sift through many files and folders to find the content of interest.
Content lacks organization and structure. There's no inherent page hierarchy to support readers.
Content versioning isn't supported.
Searching through content relies on searching the codes rather than a search experience optimized for
searching content.
With the publish code as a wiki feature, you can publish one or more Git repositories defined in your team
project to a wiki. This feature provides a way to maintain your content alongside your code base, and lets you
selectively publish and update your content to a wiki.
There are significant differences between how you manage the content for a wiki that you provision for a team
project versus wiki pages that you publish from a Git repository. For details, see Publish a Git repo to a wiki.
Markdown
Markdown makes it easy to format text and include images. You can also link to documents within your project
pages, README files, dashboards, and pull request comments.
You can provide guidance to your team in the following places using Markdown:
Team project wiki
Add Markdown to a dashboard
Project page or Welcome pages
Repository README files
Pull request comments
Add Markdown to a dashboard
Pull request comments
For supported syntax, see Syntax guidance for Markdown files, widgets, wikis, and pull request comments.
READMEs
You can define a README file or multiple files for each repo or team project. Write your README in Markdown
instead of plain text.
Use README pages to orient contributors to work within your project. Consider adding the following guidance:
Project focus
Prerequisites
Setting up the environment
Tips for getting things done within the project
Purpose or use of specific files
Project-specific terms and acronyms
Workflow guidance about committing or uploading changes and adding branches
Project sponsors or contacts
Here are some great READMEs that use this format and speak to all audiences for reference and inspiration:
ASP.NET Core
Visual Studio Code
Chakra Core
Provisioned wikis vs. published code as a wiki
In Azure DevOps, you have the following options for maintaining wiki content.
Provision a wiki for your team project. This option supports only one wiki for the team project.
Publish Markdown files defined in a Git repository to a wiki. With this option, you can maintain several
versioned wikis to support your content needs, although it's available only if Azure Repos is enabled.
While both options maintain the wiki content in Git repositories, the way you add, update, and manage the wiki
content differs.
NOTE
The publish code as wiki feature is currently available on Azure DevOps Server 2018 and later versions. For older versions,
you can only provision a wiki for your team project.
Wiki page menu options

With a provisioned wiki, you add and edit pages directly within the Wiki . All content updates to a provisioned
wiki occur within the Wiki .
With a publish code as wiki, you add, edit, and update content from Repos or Code .
The unavailable menu options for the wiki pages are shown in the following illustration. As you can see, several
options aren't supported for the publish as code wiki pages.
Provisioned wiki
For example, the Edit in Repos option for the publish code as wiki takes you to the Repo page to edit that
specific page. Updates you make to a page in the branch you selected for the wiki get automatically published to
the wiki.
Supported features and operational differences

Provisioned wikis and publish as code wikis support the following features:
Markdown format
HTML tags
Insert and resize images
Link to work items using #
Attach files
Filter Wiki contents
Print a Wiki page
Update content offline
Add or edit pages from the Wiki
The following table summarizes those operations or features that may differ, depending on the wiki type.
O P ERAT IO N P RO VISIO N ED W IK I P UB L ISH C O DE A S W IK I
Support multiple wikis, name wiki ️

✔
O P ERAT IO N P RO VISIO N ED W IK I P UB L ISH C O DE A S W IK I
Add or edit pages from Repos > Files ️

✔
or Code > Files
Revert to an earlier revision from the ️

✔
Wiki
Revert to an earlier revision from ️

✔ ️
✔
Repos or Code
Maintain versioned wikis ️

✔
Select a wiki version ️

✔
Unpublish a wiki ️
✔
Add pages
For a provisioned wiki or publish code as wiki, select New page or Add subpage . To learn more, see Add and
edit wiki pages.
Page sequence and page list in navigation pane

The provisioned wiki manages the page sequence and page list automatically as you add or move pages within
the navigation pane.
To structure the list of pages in the navigation pane for a publish code as wiki, define the .order file at the root,
and for each subfolder or parent page that contains subpages.
Both types of wikis follow the same file structure, it's just that the publish code as wiki requires you to maintain
the page sequence manually.
To learn more about working with .order files, see Wiki Git repository files and file structure.
Page revisions and reverting to a previous version

From the Wiki , you can view the revisions of any wiki page by choosing Revisions or selecting the View
revisions menu option.
However, the revert process differs depending on the wiki page type.
For a provisioned wiki page, select Rever t , as described in Revert a commit to a provisioned wiki page
For a publish as code wiki page, work from a local branch and submit a pull request to update the branch
you're working from.
Versioning and unpublishing a wiki

With versioning, you can publish different content versions to distinct wikis, based on a versioned branch of a
Git repo. Versioning and unpublishing content you've previously published to a wiki, is supported only for wikis
that you've created by publishing code to a wiki.
To learn more, see Version, select, or unpublish a published wiki.
Delete project wiki
1. Get the wiki corresponding to the wiki ID or wiki name provided. For more information, see Wikis - Get REST
API.
GET https://dev.azure.com/{organization}/{projec``t}/_apis/wiki/wikis/{wikiIdentifier}?api-version=6.0
You can also get all wikis in a project or collection. For more information, see Wikis - List REST API
2. Delete the wiki corresponding to the wiki ID or wiki name provided. For more information, see Wikis - Delete
REST API.
DELETE https://dev.azure.com/{organization}/{project}/_apis/wiki/wikis/{wikiIdentifier}?api-version=6.0
Update a wiki by working offline

You can work offline or in a local branch to update content for a provisioned wiki and publish as code wiki. To
learn more, see Clone and update wiki pages offline.
Related articles
Wiki Git repository files and file structure
Publish a Git repository to a wiki
Get Started with Git
Learn how to open a wiki and provision a Git repo for your wiki.
Every team project can have a wiki. Use the wiki to share information with your team to understand and
contribute to your project.
Git repo is not created by default. Provision a Git repository to store your wiki Markdown files, or publish
existing Markdown files from a Git repository to a wiki.
Git repo isn't created by default. Provision a Git repository to store your wiki Markdown files.
Prerequisites
You must have a team project. If you don't have a team project yet, create one in Azure DevOps.
You must have at least Basic access to create and modify a wiki.
You must have a team project. If you don't have a team project yet, create one on-premises.
Open the Wiki

Browser
Azure DevOps CLI
Provision a wiki Git repository

Browser
Azure DevOps CLI
Provision a new Git repository that stores all your wiki pages and related artifacts. From the wiki landing page,
select Create Project wiki . (Even if you use TFVC for source control, you can create a wiki with a Git
repository.)
If you don't have access to create a Wiki Git repository or if you don't have access to any of the existing wikis,
the following message appears.
Your administrator can provision the Wiki Git repository or you can request that they elevate your permissions.
Stakeholders can't create a wiki, as they have no permissions to work in Repos or Code .
The Wiki Git repo is referred as TeamProjectName.wiki. For example, if your team project is 'foobar' then the
Wiki repo is labeled 'foobar.wiki'.
NOTE
If you want to provision more wikis, then you must publish code as a wiki. You can set up multiple wiki repos within a
single project.
How can I go to the Git repository?

The TeamProjectName.wiki doesn't appear in the drop-down menu of repositories from Repos or Code . It also
isn't in the list provided from the Project Settings > Repositories or Project Settings > Version Control
pages.
However, you can get to it from the following URL:
https://dev.azure.com/<OrgName>/<TeamProjectName>/_git/<WikiName>
https://<ServerName>/DefaultCollection/<TeamProjectName>/_git/<WikiName>
Choose Clone Wiki from the ellipsis near the wiki picker to access the Wiki URL.
The URL of the wiki Git repository is exposed. Copy and paste it into your web browser to access the underlying
Git repo.
Next steps
You can add a title and content to a page, after the wiki Git repository is provisioned for your team project.
There's a side-by-side edit and preview experience where you can edit the page and preview the content as you
go.
Learn how to do the following tasks:
Open wiki
Add a wiki page
View revisions for a page
Edit and delete wiki pages
Reorder wiki pages
Make a page the wiki home page
While authoring pages using Markdown format, you can also use the format pane for rich-text formatting and
inserting images, attachments, and links.
As you edit the page, save it by entering Ctrl+S . To save with a custom revision message, select next to Save .
For more shortcuts, see Keyboard shortcuts to manage wiki pages.
Wiki command-line tools

C O M M A N DS DESC RIP T IO N
az devops wiki show Open a wiki

az devops wiki page show Get the content of a page or open a page
az devops wiki page create Add a new page
az devops wiki page update Edit a page
az devops wiki page delete Delete a page
NOTE
To add or edit pages to a wiki that you've published from a Git repository, see Publish a Git repository to a wiki. This
article addresses how to add and edit pages of a wiki that you've provisioned for a team project.
Prerequisites
You must have a provisioned wiki. If your wiki hasn't yet been created, create it now.
You must be a member of the team project as a contributor to add or update wiki pages.
You must have Basic access level to edit the project wiki.
Open the Wiki

Browser
Azure DevOps CLI
Add a wiki page

Browser
Azure DevOps CLI
To add another page, choose New page . Or, to add a subpage, open the context menu of an existing page and
select Add subpage .
Specify a unique title of 235 characters or less. Page titles are case-sensitive. For other title restrictions, see Wiki
Git repository files and file structure, File naming conventions.
You can also use keyboard shortcuts to add a new page by pressing n or add a subpage by pressing c . For a
complete list of keyboard shortcuts, see Keyboard shortcuts to manage wiki pages.
Wiki page title naming restrictions

Each wiki page corresponds to a file within the wiki Git repo. Names you assign to a wiki page title must
conform to the following restrictions.
REST RIC T IO N T Y P E REST RIC T IO N
File name The fully qualified page path shouldn't exceed 235
characters.
Uniqueness Page titles are case sensitive and must be unique within the
wiki hierarchy.
Special characters 1. Must not contain any Unicode control characters or

surrogate characters
2. Must not contain the following printable characters: /
\#
3. Must not start or end with a period (.)
File size Must not exceed the maximum of 18 MB
Attachment file size Must not exceed the maximum of 19 MB
Special characters in Wiki page titles

You can specify page titles which contain one or more of these special characters : < > * ? | - . For example,
you can name a Markdown file as "FAQ?" or "Set-up guide". The characters have the following URI encoded
strings:
C H A RA C T ER EN C O DED ST RIN G
: %3A
< %3C
> %3E
* %2A
? %3F
| %7C
- %2D
" %22
characters.
wiki hierarchy.

:<\*?\|-#
4. Titles of pages added offline must not contain a blank
space.
Edit and delete wiki pages

Browser
Azure DevOps CLI
To edit an existing wiki page, open the page and select Edit , or open the context menu and select Edit . You can
also use keyboard shortcut e to go to the edit of the current page quickly.
For code wikis, you can edit a page in the side-by-side editor, using the markdown toolbar to create your
content. This experience is identical to the process in a project wiki. You can also edit wiki pages in the Repos hub
also by using the option, Edit in Repos .
NOTE
If you have branch policies in your code wiki, use Edit in Repos to create a branch and continue editing.
To delete a page, open the context menu from the tree or the one inside the page and select Delete . Confirm the
delete in the dialog that opens.
NOTE
Deleting a page deletes the page along with all the metadata and all its subpages (if any) in the hierarchy.
Reorder a wiki page

You can reorder pages within the wiki tree view to have pages appear in the order and hierarchy you want. You
can drag-and-drop a page title in the tree view to do the following operations:
Change the parent-child relationship of a page.
Change the order of the page within the hierarchy.
NOTE
Moving a page in the hierarchy may break links to it from other pages. You can always fix the links manually after you
move. Reordering a page within a hierarchy has no impact on page links.
You can also use keyboard shortcuts to reorder pages. Select a page and press CTRL + UP ARROW or CTRL +
DOWN ARROW to change page orders. To change the parent-child relationship of a page, open its context
menu and select Move . The Move page dialog opens. Select a parent page under which you can move the
current page.
For a complete list of keyboard shortcuts, see Keyboard shortcuts to manage wiki pages.

By default, the first page you add when you create a wiki is set as the wiki home page. You can change your wiki
homepage if another page becomes more relevant by dragging and dropping the page to the top of the tree.
Next steps
View wiki page history and revert
Publish a Git repo to a wiki
You can publish content that you already maintain in a Git repo to a wiki. For example, this content could be
software development kit (SDK) support, product documentation, or a README file. You can also publish
multiple wikis within a single team project.
In this quickstart, learn how to do the following tasks:
Open wiki
Publish a Git repo to a wiki
Edit pages of a published wiki
Add pages to a published wiki
Change the page sequence of a published wiki
When you publish your Markdown files to a wiki, you gain the following benefits:
Organize the content into a hierarchical page structure
Table of contents that readers can browse and filter
Publish new versions of the content
Manage content in the same way you manage your code base
Readers can search the wiki easily using the wiki search feature
For more information about managing the different wiki types, see Provisioned vs. published code as wiki.
TIP
You can add and edit content you've published to a wiki using the steps outlined in this article. You can also work offline
and update wiki content in the same way that you collaborate on code through a Git repo. For more information, see
Update wiki pages offline.
Prerequisites
Have a team project. If you don't have one, create a project now.
Enable the Azure Repos service for your project.
Have a Git repo defined in your team project. Ideally, this repo contains at least one Markdown file, which you
want to publish to your wiki. For more information, see Create a new Git repo in your project.
Have the permission Contribute to publish code as wiki. By default, this permission is set for members of
the Contributors group. Anyone who has permissions to contribute to the Git repo can add or edit wiki
pages.
Open wiki
1. Sign in to your organization ( https://dev.azure.com/{yourorganization} ), open your project, and then
select Over view > Wiki .
If you need to switch projects, select Azure DevOps to browse all projects.
1. Sign in to your organization ( https://dev.azure.com/{yourorganization} ) and select Wiki .

Browser
Azure DevOps CLI
Do the following steps when you maintain Markdown files in an existing Git repo and you want to publish them
to a wiki.
1. Select Publish code as wiki .
NOTE
The Publish code as wiki option won't appear if your project doesn't have a Git repo defined. Create a new Git
repo, and then return and refresh this page.
2. If you've already provisioned a team project wiki, select Publish code wiki .
3. Choose the repo, branch, and folder that contain the Markdown files and enter a name for the wiki repo.
The Git repo must be within the team project.
Specify the root of the repo when you want to publish all Markdown files in the repo to your wiki.
4. Select Publish . The wiki repo populates with the Markdown files and folders included within the repo
you selected.
For example, the following image shows the published repo for the files that are contained in the azure-
docs-sdk-node repo that you selected in Step 2.
The wiki table of contents (TOC) contains the following files:
Each Markdown file (file type= .md ) defined in the repo/branch/folder is listed in alphabetical
order, the TOC title is derived from the Markdown file name.
A parent page for each subfolder defined within the published folder, even if it doesn't contain any
Markdown files.
The following image shows the contents of the azure-docs-sdk-node repo.
The head of the Git repo branch is mapped to the wiki. Any changes made within the branch and selected
folder(s) are automatically reflected in the wiki. There are no other workflows involved.
NOTE
You can publish up to 10 branches per published code wiki.
For the provisioned wiki with the extra Markdown files, you can add or edit pages in the same way that you
maintain code in your Git repo.
Edit, rename, or delete pages

Do the following steps to edit, rename, or delete a wiki page.
1. In your project, open Repos > Files or Code > Files .
2. Choose the page you want, select Actions , and then choose the operation.
NOTE
You can manage your wiki repo in the same way you manage any other Git repo by defining branch policies on the
branch that you selected to publish to a wiki. But, without any policies defined, you can make changes and push them
directly to the branch from your web portal or from a client.
Edit a page
Use the links available in edit mode to preview your changes or highlight changes made from the previous
version. To discard your changes, select Cancel . For more information about supported Markdown features, see
Syntax guidance for Markdown usage.
1. When you're done, add a comment about your updates, and then select Commit .
The system automatically presents you with a link to create a pull request. You can ignore this message
when you're directly editing the wiki branch.
TIP
When you change the name or case of a file, update the .order file to reflect the change. For more information, see
Change the page sequence, add or update an .order file.
Rename a page
All pages that you want to appear in the TOC must be the file type .md .
1. Select Rename to rename the file accordingly.
For example, in the following image, we rename new-home-page.md to New-Home-Page.md. This page appears
in the TOC with the label, "New Home Page".
Page titles are case-sensitive and must be unique within the folder, and 235 characters or less. For more
information about other title restrictions, see Page title naming restrictions.
Delete a page
You can delete any Markdown files that you don't want to appear in the wiki from the published folder. If you've
included the file in an .order file, then delete its entry from the .order file. For more information, see Change
the page sequence, add, or update an .order file.
Add a page or pages

You can add the following pages to your published wiki:
Add a file to a root folder or subfolder from the web portal
Upload files to a root folder or subfolder
Add or update an .order file to specify the page sequence in the wiki TOC
Each update requires you to commit your changes to the repo. You can then refresh your wiki for your published
repo to review the changes.
Add a page from the web portal
1. From Repos > Files or Code > Files for the published repo, select Actions , and then choose File .
2. Enter a name for the page, make sure to specify the .md file type. The file name should correspond to the
page title that you want to appear in the TOC, with dashes in place of spaces. Specify a unique title of 235
characters or less. Page titles are case-sensitive. For more information about other title restrictions, see
Page title naming restrictions.
For example, to add a page that appears in the TOC as Page 4, add a file named Page-4.md .
3. Enter the contents of the page. For more information, see Syntax guidance for Markdown files, widgets,
wikis, and pull request comments.
4. When you're done, select Commit .
Upload files to a folder
1. If you have existing content already defined, you can upload it to a folder. Select Actions , and then
choose Upload file(s) .
2. Complete the Commit dialog form, selecting the folder and files you want to upload.
Add a parent page and subpages

To add a parent page, first add a Markdown file at the root folder level and then add a folder with the same label.
1. To add a folder, select Folder , and then complete the New Folder dialog form. Specify at least one file to
correspond to a subpage in the folder.
2. Add all the files you want as subpages to the folder.
Add or update an .order file
The last step when you're adding files or folders to the wiki repo is to add or update the .order file of the
updated folders. This action reflects the sequence of pages you want to show in the TOC. For details, see Change
the page sequence, add, or update a .order file. Any files that aren't listed in the .order file get added to the end
of the alphabetical list, as their order is set to int.MaxValue .
Change the page sequence, add, or update an .order file

Each .order file defines the sequence of pages contained within a folder. The root .order file specifies the
sequence of pages defined at the root level. For each folder, an .order file defines the sequence of subpages
added to a parent page.
1. You can add an .order file in the same way that you add any file from the Code > Files page. Name the
file .order .
2. Edit the contents of the file to reflect the sequence of Markdown files contained within the folder. Each
entry should mirror the file name but without the .md file type. Titles are case-sensitive, so the entry
should match the case used in the file name.
For example:
README
page-2
page-3
Page-4
Misc content
Set a home page

By default, the first file that appears at the root within alphabetical order is set as the wiki home page. When you
select Wiki in the web portal, the home page opens.
1. Change the home page by setting the page sequence within the root .order file.
For example, enter the page name into the first line:
New home page name here
page-2
page-3
Page-4
README
Misc content
Promote folder to page

For a folder to also be a page, you need a Markdown file with the same name as the folder, set as a sibling to the
folder. So, both the folder and the .md file of the same name should lie next to each other.
As displayed in the following example, Test has both a folder and an .md file, which creates a hierarchy within
the wiki tree.
Next steps
Un-publish a wiki or select a version
Related articles
Follow a wiki page and get notifications
Provisioned vs. published wiki
Update wiki offline
Wiki files and file structure
Learn about the files and file structure for project wikis and code wikis. The following guidance might specify
code wikis, however it applies to both types of wiki.
When you create a team project, a wiki isn't created by default. For more information about creating wikis, see
Create a wiki for your project.
Each code wiki is powered by a Git repository in the back-end. This repository stores the Markdown pages,
images, attachments, and the sequence of pages and subpages. You create your wiki via the Azure DevOps user
interface, and then you can edit the wiki via your Git repository URL path. For more information about
publishing code wikis, see Publish a Git repository to a wiki.
Wiki file and folder structure

The team project wiki Git repositories are assigned the following labels.
Wiki repo for a team project: ProjectName.wiki
Main branch: wikiMain
NOTE
You can manage your wiki repo in the same way you manage any other Git repo, by defining branch policies on the
wikiMain branch. However, you can make changes to your local wikiMain branch and push them directly to the remote
branch without defining any policies.
The wiki repository has the following files and folders:

File for each Markdown page entered at the root level
File labeled .order at the root and under each folder
Folder for each page that has subpages
.attachments folder, storing all the attachments of the wiki
File naming conventions

Each file requires using hyphens instead of spaces in the page title. For example, the "How to contribute" page
title corresponds to the How-to-contribute.md file name. The page name gets added to the URL, ensuring
that links you share remain intact as the wiki changes over time.
Each wiki page corresponds to a file within the wiki Git repo. Names you assign to a wiki page title must
conform to the following restrictions.
characters.
wiki hierarchy.

\#
Special characters in Wiki page titles

You can specify page titles which contain one or more of these special characters : < > * ? | - . For example,
you can name a Markdown file as "FAQ?" or "Set-up guide". The characters have the following URI encoded
strings:
C H A RA C T ER EN C O DED ST RIN G
: %3A
< %3C
> %3E
* %2A
? %3F
| %7C
- %2D
" %22
characters.
wiki hierarchy.

:<\*?\|-#
4. Titles of pages added offline must not contain a blank
space.
.order file
The .order file defines the sequence of pages within the wiki. The following visual shows an example of a wiki
TOC and it's corresponding .order file.
W IK I TO C . O RDER F IL E
The default hierarchy is in alphabetical sequence, however you can change this hierarchy in the .order file. For
more information about how to reorder wiki pages, see Add and edit wiki pages, Reorder a wiki page.
Delete the .order file to revert to alphabetical sorting
When there's no .order file the pages get sorted alphabetically. To revert to alphabetical sorting, do the following
steps:
1. Copy the clone URL for the wiki and open it in a browser. Doing so opens the Git repository (files hub), which
backs the wiki.
2. Go to the .order file and delete it. The .order file gets automatically (re)created after deletion, for example, in a
drag and drop action on an article.
Related articles
Set up wiki vs. publish code as wiki
Manage README and wiki permissions
Create a README for your repo
Your Git repo should have a readme file so that viewers know what your code does and how they can get
started using it. Your readme should speak to the following audiences:
Users that just want to run your code.
Developers that want to build and test your code. Developers are also users.
Contributors that want to submit changes to your code. Contributors are both developers and users.
Write your readme in Markdown instead of plain text. Markdown makes it easy to format text, include images,
and link as needed to more documentation from your readme.
Here are some great readmes that use this format and speak to all three audiences, for reference and
inspiration:
ASP.NET Core
Visual Studio Code
Chakra Core
Create an intro
Start off your readme with a short explanation describing your project. Add a screenshot or animated GIF in
your intro if your project has a user interface. If your code relies on another application or library, make sure to
state those dependencies in the intro or right below it. Apps and tools that run only on specific platforms should
have the supported operating system versions noted in this section of the readme.
Help your users get started

Guide users through getting your code up and running on their own system in the next section of your readme.
Stay focused on the essential steps to get started with your code. Link to the required versions of any
prerequisite software so users can get to them easily. If you have complex setup steps, document those outside
your readme and link to them.
Point out where to get the latest release of your code. A binary installer or instructions on using your code
through packaging tools is best. If your project is a library or an interface to an API, put a code snippet showing
basic usage and show sample output for the code in that snippet.
Provide build steps for developers

Use the next section of your readme to show developers how to build your code from a fresh clone of the repo
and run any included tests. Do the following:
Give details about the tools needed to build the code and document the steps to configure them to get a
clean build.
Break out dense or complex build instructions into a separate page in your documentation and link to it if
needed.
Run through the instructions as you write them in order to verify the instructions would work for a new
contributor.
Remember, the developer relying on these instructions could be you after not working on a project for some
time.
Provide the commands to run any test cases provided with the source code after the build is successful.
Developers lean on these test cases to ensure that they don't break your code as they make changes. Good test
cases also serve as samples that developers can use to build their own test cases when adding new functionality.
Help users contribute

The last section of your readme helps users and developers to get involved in reporting problems and suggest
ideas to make your code better. Users should be linked to channels where they can open up bugs, request
features, or get help using your code.
Developers need to know what rules they need to follow to contribute changes, such as coding/testing
guidelines and pull request requirements. If you require a contributor agreement to accept pull requests or
enforce a community code of conduct, this process should be linked to or documented in this section. State what
license the code is released under and link to the full text of the license.
Manage wikis with the CLI
Azure DevOps Ser vices

Learn the following CLI commands for managing wikis.
NOTE
You can't delete project wikis with the CLI.
Commands
az devops wiki create Create a wiki.
az devops wiki delete Delete a wiki.
az devops wiki list List all the wikis in a project or an organization.
az devops wiki page Manage wiki pages.
az devops wiki page create Add a new page.
az devops wiki page delete Delete a page.
az devops wiki page show Get the content of a page or open a page.
az devops wiki page update Edit a page.
az devops wiki show Show the details of a wiki.
Create a wiki
To create a wiki, enter the az devops wiki create command.
az devops wiki create [--mapped-path]

[--name]
[--project]
[--repository]
[--subscription]
[--type {codewiki, projectwiki}]
Optional parameters
--mapped-path : [Required for codewiki type] Mapped path of the new wiki, for example, '/' to publish from
root of repository. --name: Name of the new wiki.
--project -p : Optional. Name or ID of the project. You can configure the default project using az devops
configure -d project=NAME_OR_ID. Required if not configured as default or picked up via git config.
--repositor y -r : [Required for codewiki type] Name or ID of the repository to publish the wiki from.
--subscription : Optional. Name or ID of subscription. You can configure the default subscription using
az account set -s NAME_OR_ID .
--type --wiki-type : Type of wiki to create. Accepted values: codewiki, projectwiki. Default value: projectwiki.
Examples
Create a named project wiki.
az devops wiki create --name myprojectwiki
Create a code wiki from a folder in a code repository.
az devops wiki create --name WIKI_NAME --type codewiki

--repository REPO_NAME --mapped-path PATH_TO_PUBLISH
Delete a wiki
To delete a wiki, enter the az devops wiki delete command.
NOTE
You can use this command only to delete a code wiki. You can't use the command to delete a project wiki.
az devops wiki delete

[--wiki]
[--project]
[--subscription]
[--yes]
Parameters
--wiki : Required. Name or ID of the wiki to delete.
--project -p : Optional. Name or ID of the project. You can configure the default project using az devops
configure -d project=NAME_OR_ID. Required if not configured as default or picked up via git config.
--yes -y : Optional. Don't prompt for confirmation.
Example
Delete a wiki without a prompt for confirmation.
az devops wiki delete --wiki myprojectwiki --yes
List wikis
To list all the wikis in a project or an organization, enter the az devops wiki list command.
az devops wiki list
[--project]
[--scope {organization, project}]
[--subscription]
Optional parameters
--project -p : Optional. Name or ID of the project.
--scope : Optional. List the wikis at project or organization level. Accepted values: organization, project.
Default value: project.
Examples
List all wikis for a project.
az devops wiki list
List all wikis in the organization.
az devops wiki list --scope organization
Show wiki
To show details of a wiki, enter the az devops wiki show command.
az devops wiki show --wiki

[--open]
[--project]
[--subscription]
Parameters
--wiki : Required. Name or ID of the wiki.
--open : Optional. Open the wiki page in your web browser.
Example
Show the wiki named 'myprojectwiki' and open the wiki page in your web browser.
az devops wiki show --wiki myprojectwiki --open
Create a wiki page

To add a new wiki page, enter the az devops wiki page create command.
az devops wiki page create --path
--wiki
[--comment]
[--content]
[--encoding {ascii, utf-16be, utf-16le, utf-8}]
[--file-path]
[--project]
[--subscription]
Parameters
--path : Required. Path of the wiki page.
--wiki : Required. Name or ID of the wiki.
--comment : Optional. Comment in the commit message of file add operation. Default value: Added a new
page using Azure DevOps CLI.
--content : Optional. Content of the wiki page. Ignored if --file-path is specified.
--encoding : Optional. Encoding of the file. Used with --file-path parameter.
--file-path : Optional. Path of the file input if content is specified in the file.
--subscription : Name or ID of subscription. You can configure the default subscription using az account set
-s NAME_OR_ID.
Examples
Create a new page with path 'my page' in a wiki named 'myprojectwiki' with inline content.
az devops wiki page create --path 'my page' --wiki myprojectwiki --content "Hello World"
Create a new page with path 'my page' in a wiki named 'myprojectwiki' with content from a file.
az devops wiki page create --path 'my page' --wiki myprojectwiki --file-path a.txt --encoding utf-8
View wiki page history and revert changes
You can see details of the changes made to a wiki page and revert to an earlier version, if needed.
View wiki page revision history

1. To view the revision history of a page, select the Revisions link provided on each page. You can also
select View revisions in the context menu of a page.
2. Revision pages show who made the change along with the revision message, date, and version or
commit ID. To view details of a revision, select the message or version link.
3. Similar to any git file revision, the revision details page provides a Show diff side-by-side view or the
Show diff inline view. Choose Preview to see the content of the page of the specific revision.
For a publish as code wiki page, you see similar information, but Rever t isn't active.
4. Use the breadcrumbs to return to the page or revisions of the page.
Revert a commit to a provisioned wiki page

Select Rever t on the revision details page to revert a change on a wiki page.
NOTE
The Rever t option is available with TFS 2018.2 and later versions.
Revert a commit to a publish as code wiki page
If you need to revert to an earlier revision for a page that you've published as code, do one of the following
actions:
If the commit is the most recent revision to a page, you can revert from the web portal.
If the commit is an earlier revision, with additional commits having occurred in between, create a separate
branch and revert the changes in that branch.
Revert from a recent revision from the web portal
1. Preview any version by choosing the commit ID from the Revisions page for the selected file.
2. Copy the full ID of the commit by selecting Copy-clone . Here we copy the commit ID,
ca6d475a22eb1db930cf238f3b80862a78a689e4 , with the abbreviated ID of ca6d475a .
3. Open the Repos > Commits page and paste the ID that you copied into the Commit ID box and choose
Search.
4. From the commit page, select More actions , and then choose Rever t .
5. Confirm that you want to revert. Choose Rever t in the dialog.

A branch is created with the reverted changes.
6. Select Create Pull Request .
If instead, you receive an error message as shown, it indicates that you must create a local branch and
make your changes manually as described in the next section.
7. Select Create in the New Pull Request form.

8. Select Complete to merge the changes into the main wiki branch. Optionally, check the Delete checkbox
to delete the intermediate branch.
Return to the wiki, refresh the browser, and you should see the reverted content.
Revert from earlier revisions using a different branch
To revert to an earlier committed version of a publish as code wiki page (one that isn't the immediate last
revision), you must update a branch other than the main branch for the wiki, and then create a pull request to
the main branch.
1. Create a local branch of the main wiki branch.
2. View the commit history and locate the commit that contains the changes you want to undo.
3. Use the revert command to revert the desired commit.
4. When a conflict arises, use the conflict resolution tools to resolve the issues.
5. Commit the changes locally to your local branch.
6. Push the local branch to the remote server.
7. Create a pull request for your local branch into main.
8. Complete the pull request.
You can use the following steps to identify the commit that contains the content you want to revert to. Then, use
standard Git operations to revert the content.
For more information, see the following articles:
Clone an existing Git repo
Create work in branches
Review history
Undo (revert) changes
Resolve merge conflicts
Copy changes with cherry-pick
Commit details
Related articles
Differences between provisioned wiki and publish code as wiki
Manage README and Wiki permissions
Filter the contents of a wiki or print a page
To focus on a single page or several pages, use the Filter pages feature in the table of contents (TOC). Or, to find
pages containing a phrase or keyword, you can use the search function.
To print a wiki page, you can select a page and then print it.
Filter wiki pages

Enter a title, keyword, or character string into the Filter pages by title box to quickly find pages whose title
contains the keyword.
Print a wiki page

The Print page menu option allows you to use your browser print function to send a page to a printer or save
as a PDF. Currently, you can only print a single page at a time.
NOTE
The Print page feature is supported on TFS 2018.2 or later versions..
NOTE
The print feature may not be available from the Firefox web browser.
Follow a wiki page, get notifications

Follow a Wiki page and get notified by email whenever the page is edited, deleted, or renamed.
Get immediate notifications for rename and delete. For edit notifications, you get a 30-minute digest email with
all edits that occurred within that period. This digest prevents the emails from spamming your inbox.
When you create a page, you become a default follower of the page. You can unfollow the page in the following
two ways:
From within the UI
From within the footer of your email notification
To reduce noise, you don’t get notified for pages that you follow when the action is performed by you.
NOTE
When a page is deleted, all followers are removed.
Related articles
Share code with push
Syntax guidance for Markdown files, widgets, wikis, and pull request comments
Create and embed a work item from wiki
Azure DevOps Ser vices | Azure DevOps Ser ver 2022 | Azure DevOps Ser ver 2020
Create and embed work items in your wiki page content. This feature gives you an easy way to promote text to a
link to a feature, task, or user story.
Create and embed work item

1. Sign in to your organization ( https://dev.azure.com/{yourorganization} ), and then select your project .
2. Select your wiki .

3. Highlight the text, and then select the type of work item you want to create from the New work item
dropdown menu. The work item form opens with the selected text added as the title and description of
the work item.
4. Add information to the work item, such as entering an assignee in the Assign To box, and then select
Save & Close .
The selected content in the wiki page is replaced with the embedded work item.
NOTE
Only Markdown plain text (including bold and italics) are replaced in the wiki page. For the rest of the content like images,
code blocks, and videos the work item is created, but the embed must be done manually. This is to prevent the page from
breaking due to the replaced work item. For more information, see how to link to work items from a Wiki page.
Show work item status

The status, ID, and title of an embedded work item is shown in the wiki page. Work item references in pull
request comments and Boards discussions also show the status.
Add comments to wiki pages
Learn how to add comments to wiki pages for better collaboration.
Add a comment
Add a comment at the bottom of any wiki page. Comments are posted on a per-branch basis. For example, if
you make a comment on a wiki page on the main branch, it doesn't appear in another published branch of a file
of the same name. Comments are stored on the internal database. For more information, see Data locations for
Azure DevOps.
View Markdown and preview tabs

When you add a Markdown-based comment, there's a Markdown editor and preview tab. Use these tabs to view
and change how the comment is rendered before you add it. You can also @mention users and groups. This
@mention sends an email notification to each user or group, with a link to the wiki page.
Edit or delete comment
Edit or delete any comments that you've added to a wiki.
Related articles
Follow wiki pages, get notifications
Create and embed a work item from wiki content
Version, select, or unpublish a wiki
Markdown guidance
Publish, unpublish, and select version of a wiki
Azure DevOps Ser vices | Azure DevOps Ser ver 2022 - Azure DevOps Ser ver 2019
When you publish a Git repository to a wiki, you can publish new branch of the repo as versions, select a version
to view, or unpublish the repo.
Publish a new wiki branch

If your published wiki corresponds to a product version, you can publish new branches as you release new
versions of your product. To create a new version, create a new branch of your repo, and then make updates to
that new branch.
1. To create a new branch from the web portal, select Repos > Branches , select Actions for the branch
you previously published, and then select New branch .
2. To publish the new branch to a wiki, open the Wiki page for the currently published branch, open the
branch picker, and then choose Publish new branch .
3. Complete the form, choosing the branch that you previously created.
4. Select Publish .
Select a wiki version

To select a wiki version, choose the version from the branch options from the Wiki page.
Unpublish a published wiki
If you no longer want a repository to be published as a wiki, you can choose to unpublish it from Wiki .
NOTE
Unpublishing a wiki unpublishes the entire code wiki, which includes all versions of the repository that you have published
previously.
1. Select the wiki you want to unpublish, open the context menu, and select Unpublish wiki .
2. Confirm that you want to unpublish the wiki by choosing Unpublish .
Related articles
Provisioned wiki vs. publish code as wiki
Clone and update wiki content offline
You can update your wiki pages offline the same way you develop code in a Git repo.
NOTE
GIT workflows, like branch policies, are applicable only for publish code as wiki workflows.
You can use any client you want or git command-line tools to update your wiki offline. For details on working
with Git repositories and supported tools, see Git Repositories.
The basic steps to update wiki content offline are as follows:
1. Clone your wiki Git repo to your local IDE or workspace.
2. Add files or folders to your local git branch.
3. Update the .order files to reflect the pages and sub-pages that you've added.
4. Commit and push the updates you made to your local git branch.
Prerequisites
Do the following steps to migrate Markdown pages from another wiki to your team project wiki or to content
that you publish as code to a wiki.
Understand the underlying structure of your wiki Git repo
Understand the differences between provisioned wiki and publish code as wiki
Do the following steps to migrate Markdown pages from another wiki to your team project wiki.
Understand the underlying structure of your wiki Git repo.
Clone your wiki

Your wiki repository stores pages, images, attachments, and the sequence of pages and subpages. Clone your
wiki to begin.
1. Sign in to your organization ( https://dev.azure.com/{yourorganization} ), select your project, and then
select your wiki.
2. Open the More actions context menu and select Clone wiki .
3. From the Clone repo dialog, select Copy clone URL to clipboard .
Enter it in your browser to view the files defined under the wikiMaster branch.
4. Use the URL that you copied to clone the repo in the IDE that you use. To learn more, see one of the
following articles:
Using Version Control in VS Code
Get Started with Git and Azure DevOps
Add pages to your local Git repository

We author pages using Markdown format. Add a Markdown file to your local branch for each page and subpage
that you want to add to your wiki.
Add pages
To add pages at the root of the wiki tree, add a Markdown file at the root of the Git repository.
1. For each page you want to add, create a Markdown file with the page contents, and then add it under the
root folder for your repo.
For the CanaryBuilds team project, it's in the following folder:
C:\Users\UserName\Source\Repos\CanaryBuilds.wiki
2. To add pages at the root of the wiki tree, add a Markdown file for each page at the root of the Git
repository.
3. After you've added all the pages you want to add at the root, update the .order file at the root. It should
have one entry for each Markdown file that is defined at the root. Each entry should match the file title
with spaces replaced with a dash.
For example:
Welcome
Roadmap
How-to-contribute
Home
Reference
Add subpages
1. Create a folder for the parent page, and then add Markdown files for each subpage in the folder.
For example, we added the following files to the How-to-contribute folder. These subpages appear under
the How to contribute page in the wiki.
2. Add a .order file in the folder with the order of the sub-pages as they should appear in the wiki. To
understand the use of the .order file to sequence pages, see Wiki Git repository files and file structure.
For example, the file has the following sub-pages:
Request-extensions
Licensing
Smoke-test
Coding-guidelines
Push your changes

When you're done with all your updates, push the files to the Git repository.
The added pages and subpages appear immediately in your wiki.
If there are any errors in the process, the pages appear in your wiki with a warning sign.
Related articles
Share code with push
Syntax guidance for Markdown files, widgets, wikis, and pull request comments.
Manage Wiki permissions
Learn about managing permissions for your wiki. By default, all members of the Contributors group can edit
Wiki pages.
Manage wiki permissions

By default, all project contributors have read and edit access of the wiki repository. You can grant or restrict
access to who can read and edit wiki pages by managing the wiki repository permissions. For more information
about permissions in Azure DevOps, see Get started with permissions, access, and security groups.
NOTE
Feature availability : The built-in wiki is available with TFS 2018 and later versions.
To open the Security dialog, choose More actions > Wiki security .
For definitions of each repository permission, see Git repository permissions.
Don't have access to create a page?
If you don't have access to create a wiki page, you need to contact an administrator to grant you adequate
permission on the underlying Git repository of the wiki.
Stakeholder wiki access

Private projects
Users with Stakeholder access in a private project can read provisioned wiki pages and view revisions,
however they can't do any edit operations. For example, Stakeholders can't create, edit, reorder, or revert
changes to project wiki pages. These permissions can't be changed.
Stakeholders have zero access to read or edit published code wiki pages in private projects. For more
information, see the Stakeholder access quick reference for project and code wikis.
Public projects
Stakeholders have full access to wikis in public projects.
For more information about Stakeholder access, see About access levels, Stakeholder access, Public versus
private feature access.
FAQ
Q: Is it possible to grant permissions on a per-page basis?
A: No, permissions to access the wiki are made for all pages and not individual pages.
Related articles
Default Git repository and branch permissions
Get Started with Git
Migrate pages from Wiki extension to a team
project wiki
This article helps you migrate pages made using the Wiki Marketplace extension to your team project Wiki. With
the release of the built-in wiki, any wiki pages created using the Wiki Marketplace extension have been saved to
a Git repo in your team project.
The Wiki feature is available for TFS 2018 and later versions. To learn more, see Create a wiki for your team
project.
Prerequisites
You must be a member of the Contributors group of your team project to migrate wiki pages to your team
project Wiki.
Migrate pages and other artifacts

1. Clone vsts-wikiTools repository and compile the MigrateToVSTSWiki tool
2. Create, and then clone your Azure DevOps wiki
3. Move and commit all Markdown pages to your Azure DevOps wiki
4. Run the wiki migration tool, MigrateToVSTSWiki.exe
5. When the wiki migration tool is complete, push the changes to the default main branch, wikiMain, of the
Azure DevOps wiki repository.
Detailed steps
1. Clone vsts-wikiTools repository and compile the MigrateToVSTSWiki tool
2. Compile the project under the path Tools/MigrateToVSTSWiki to generate the migration tool EXE.
3. From a web browser, open your Azure DevOps team project and create your first wiki page.
4. Get the URL to clone your wiki. See Clone your wiki and edit wiki pages offline.
Name this clone location "LocationA" for this procedure.
5. Clone your Wiki repo using your IDE or git clone command.
6. Clone the Wiki extension repo. The Wiki is mapped to a folder given to you during the wiki creation. You
6. Clone the Wiki extension repo. The Wiki is mapped to a folder given to you during the wiki creation. You
can confirm by going to the "manage wiki" option in the existing wiki, as shown below.
Your existing wiki pages are saved under the folder labeled "Root".
For example, you cloned the previously mentioned "sampleWiki" in the location "C:\wiki\sampleWiki".
The wiki pages are saved in the path "C:\wiki\sampleWiki\ _extensionWiki"
Name this location "LocationB" for this procedure.
7. Create an empty folder in any path on your local machine, and name it "LocationC" for this procedure.
In summar y, the following locations are represented as follows:
Location A = Azure DevOps Wiki repo
Location B = Wiki extension repo
Location C = Empty folder to run migration tool in
8. Open a command prompt as an administrator and run MigrateToVSTSWiki.exe . This tool copies the
files from your existing wiki to the destination directory you provide. During copying, the tool converts
the pages to be compliant with the Azure DevOps wiki.
MigrateToVSTSWiki.exe /source:LocationB /destination:LocationC
For example:
"E:\wiki\sampleWiki_extensionWiki" is the folder in which the existing wiki files are present
"E:\Temp\Wiki\New" is the empty folder into which the migrated files are to be copied.
9. Remove all files from "LocationA" (if any) apart from the git related files, such as .gitignore, and so on.
10. Copy all files from "LocationC" and paste them into "LocationA".
11. Run **git add .** to stage all the newly added files in "LocationA" for the commit.
12. Run **git commit -m <commit message>** to commit the files that you have staged locally.
13. Run git push origin wikiMain -f . to push the changes to the default branch of the Azure DevOps Wiki.
NOTE
Once you've migrated your Wiki extension files to the Azure DevOps Wiki, you're ready to uninstall the Wiki extension.
Related articles
Wiki page title naming conventions
Clone and update wiki pages offline
Source code for the wiki tools
Git quickstart
Contributions
This project has adopted the Microsoft Open Source Code of Conduct. For more information, see the Code of
Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
Syntax guidance for basic Markdown usage
IMPORTANT
working from Azure DevOps Services or an on-premises version of Azure DevOps Server, renamed from Team Foundation
Server (TFS).
Here you can find some basic Markdown syntax guidance and specific guidance for using Markdown in Azure
DevOps features. You can use both common Markdown conventions and GitHub-flavored extensions.
Having the right guidance at the right time is critical to success. Use Markdown to add rich formatting, tables,
and images to your project pages, README files, dashboards, and pull request comments.
For more syntax that's supported for Wiki pages, see Wiki Markdown guidance.
You can provide guidance in the following areas using Markdown:
Project wiki
Markdown widget added to a dashboard
Pull request (PR) comments
Definition of Done (Kanban board)
Project wiki
Markdown widget added to a dashboard
Pull request (PR) comments
Definition of Done (Kanban board)
NOTE
Rich Markdown rendering in code repositories is supported for TFS 2018.2 and later versions. You can create rich
README.md files in the code repositories. The Markdown rendering of the MD files in code repositories supports HTML
tags, block quotes, emojis, image resizing, and mathematical formulas. There is parity in Markdown rendering in Wiki and
MD files in code.
IMPORTANT
Not all Markdown syntax is supported across all features. Each section in this article identifies the features the syntax is
supported with the Suppor ted in line.
Headers
Supported in: Definition of Done | Markdown widget | Pull Requests | README files | Wikis
Structure your comments using headers. Headers segment longer comments, making them easier to read.
Start a line with a hash character # to set a heading. Organize your remarks with subheadings by starting a line
with more hash characters, for example #### . Up to six levels of headings are supported.
Example:
# This is a H1 header
## This is a H2 header
### This is a H3 header
#### This is a H4 header
##### This is a H5 header
Result:
Paragraphs and line breaks

Make your text easier to read by breaking it into paragraphs or with line breaks.
Pull requests
In pull request comments, select Enter to insert a line break, and begin text on a new line.
Example - pull request comment:
Add lines between your text with the **Enter** key.

Your text gets better spaced and makes it easier to read.
Result:
Add lines between your text with the Enter key.
Your text gets better spaced and makes it easier to read.
Markdown files or widgets
In a Markdown file or widget, enter two spaces before the line break, and then select Enter to begin a new
paragraph.
Example - Markdown file or widget:
Add two spaces before the end of the line, and then select **Enter**.(space, space, Enter)
A space gets added in between paragraphs.
Result:
Add two spaces before the end of the line, and then select Enter.
A space gets added in between paragraphs.
Blockquotes
Quote previous comments or text to set the context for your comment or text.
Quote single lines of text with > before the text. Use many > characters to nest quoted text. Quote blocks of
lines of text by using the same level of > across many lines.
Example:
> Single line quote

>> Nested quote
>> multiple line
>> quote
Result:
Horizontal rules
To add a horizontal rule, add a line that's a series of dashes --- . The line above the line containing the ---
must be blank.
Example:
above
----
below
Result:
above
below
Emphasis (bold, italics, strikethrough)

You can emphasize text by applying bold, italics, or strikethrough to characters:
To apply italics: surround the text with an asterisk * or underscore _
To apply bold: surround the text with double asterisks ** .
To apply strikethrough: surround the text with double tilde characters ~~ .
Combine these elements to apply emphasis to text.
NOTE
There is no Markdown syntax that supports underlining text. Within a wiki page, you can use the HTML tag to
generate underlined text. For example, underlined text yields underlined text.
NOTE
There is no Markdown syntax that supports underlining text. Within a wiki page in TFS 2018.2 and later versions, you can
use the HTML tag to generate underlined text. For example, underlined text yields underlined text.
Example:
Use _emphasis_ in comments to express **strong** opinions and point out ~~corrections~~
**_Bold, italicized text_**
**~~Bold, strike-through text~~**
Result:
Use emphasis in comments to express strong opinions and point out corrections
Bold, italicized text Bold, strike-through text
Code highlighting
Supported in: Pull Requests | README files | Wikis
Highlight suggested code segments using code highlight blocks. To indicate a span of code, wrap it with three
backtick quotes ( ``` ) on a new line at both the start and end of the block. To indicate code inline, wrap it with
one backtick quote ( ` ).
NOTE
Code highlighting entered within the Markdown widget renders code as plain preformatted text.
Example:
```
sudo npm install vsoagent-installer -g
```
Result:
sudo npm install vsoagent-installer -g
Example:
To install the Microsoft Cross Platform Build & Release Agent, run the following: `$ sudo npm
install vsoagent-installer -g`.
Result:
To install the Microsoft Cross Platform Build & Release Agent, run the following command:
$ sudo npm install vsoagent-installer -g .
Within a Markdown file, text with four spaces at the beginning of the line automatically converts to a code block.
Set a language identifier for the code block to enable syntax highlighting for any of the supported languages in
highlightjs, version v9.10.0.
``` language
code
```
More examples:
``` js
const count = records.length;
```
const count = records.length;
``` csharp
Console.WriteLine("Hello, World!");
```
Console.WriteLine("Hello, World!");
Tables
Supported in: Markdown widget | Pull Requests | README files | Wikis
Organize structured data with tables. Tables are especially useful for describing function parameters, object
methods, and other data that have a clear name to description mapping. You can format tables in pull requests,
wiki, and Markdown files such as README files and Markdown widgets.
Place each table row on its own line
Separate table cells using the pipe character |
The first two lines of a table set the column headers and the alignment of elements in the table
Use colons ( : ) when dividing the header and body of tables to specify column alignment (left, center, right)
To start a new line, use the HTML break tag ( ) (Works within a Wiki but not elsewhere)
Make sure to end each row with a CR or LF.
A blank space is required before and after work item or pull request (PR) mentions inside a table cell.
Example:
| Heading 1 | Heading 2 | Heading 3 |

|-----------|:-----------:|-----------:|
| Cell A1 | Cell A2 | Cell A3 |
| Cell B1 | Cell B2 | Cell B3 second line of text |
Result:
H EA DIN G 1 H EA DIN G 2 H EA DIN G 3
Cell A1 Cell A2 Cell A3
Cell B1 Cell B2 Cell B3

second line of text
Lists
Organize related items with lists. You can add ordered lists with numbers, or unordered lists with just bullets.
Ordered lists start with a number followed by a period for each list item. Unordered lists start with a - . Begin
each list item on a new line. In a Markdown file or widget, enter two spaces before the line break to begin a new
paragraph, or enter two line breaks consecutively to begin a new paragraph.
Ordered or numbered lists
Example:
1. First item.
1. Second item.
1. Third item.
Result:
1. First item.
2. Second item.
3. Third item.
Bulleted lists
Example:
- Item 1
- Item 2
- Item 3
Result:
Item 1
Item 2
Item 3
Nested lists
Example:
1. First item.
- Item 1
- Item 2
- Item 3
1. Second item.
- Nested item 1
- Further nested item 1
- Nested item 2
- Nested item 3
Result:
1. First item.
Item 1
Item 2
Item 3
2. Second item.
Nested item 1
Further nested item 1
Nested item 2
Nested item 3
Links
In pull request comments and wikis, HTTP and HTTPS URLs are automatically formatted as links. You can link to
work items by entering the # key and a work item ID, and then choosing the work item from the list.
Avoid auto suggestions for work items by prefixing # with a backslash ( \ ). This action can be useful if you want
to use # for color hex codes.
In Markdown files and widgets, you can set text hyperlinks for your URL using the standard Markdown link
syntax:
[Link Text](Link URL)

When you're linking to another Markdown page in the same Git or TFVC repository, the link target can be a
relative path or an absolute path in the repository.
Suppor ted links for Welcome pages:
Relative path: [text to display](target.md)
Absolute path in Git: [text to display](/folder/target.md)
Absolute path in TFVC: [text to display]($/project/folder/target.md)
URL: [text to display](http://address.com)
Suppor ted links for Markdown widget:

Suppor ted links for Wiki:

Absolute path of Wiki pages: [text to display](/parent-page/child-page)
NOTE
Links to documents on file shares using file:// aren't supported on 2017.1 and later versions. This restriction has
been implemented for security purposes.
For information on how to specify relative links from a Welcome page or Markdown widget, see Source control relative
links.
Example:
[C# language reference](/dotnet/csharp/language-reference/)
Result:
C# language reference
Source control relative links

Links to source control files are interpreted differently depending on whether you specify them in a Welcome
page or a Markdown widget. The system interprets relative links as follows:
Welcome page: relative to the root of the source control repository in which the welcome page exists
Markdown widget: relative to the team project collection URL base
For example:
W EL C O M E PA GE M A RK DO W N W IDGET EQ UIVA L EN T
/BuildTemplates/AzureContinuousDeploy.11.xaml /DefaultCollection/Fabrikam
Fiber/_versionControl#path=$/Tfvc
Welcome/BuildTemplates/AzureContinuousDeploy.11.xaml
./page-2.md /DefaultCollection/Fabrikam
Fiber/_versionControl#path=$/Tfvc Welcome/page-2.md
Anchor links
Within Markdown files, anchor IDs are assigned to all headings when rendered as HTML. The ID is the heading
text, with the spaces replaced by dashes (-) and all lower case. In general, the following conventions apply:
Punctuation marks and leading white spaces within a file name are ignored
Upper case letters are converted to lower
Spaces between letters are converted to dashes (-).
Example:
###Link to a heading in the page
Result:
The syntax for an anchor link to a section...
[Link to a heading in the page](#link-to-a-heading-in-the-page)
The ID is all lower case, and the link is case-sensitive, so be sure to use lower case, even though the heading itself
uses upper case.
You can also reference headings within another Markdown file:
[text to display](./target.md#heading-id)
In wiki, you can also reference heading in another page:
[text to display](/page-name#section-name)
Images
Supported in: Markdown widget | Pull Requests | README files | Wikis
To highlight issues or make things more interesting, you can add images and animated GIFs to the following
aspects in your pull requests:
Comments
Markdown files
Wiki pages
Use the following syntax to add an image:
![Text](URL)
The text in the brackets describes the image being linked and the URL points to the image location.
Example:
![Illustration to use for new users](https://azurecomcdn.azureedge.net/cvt-

779fa2985e70b1ef1c34d319b505f7b4417add09948df4c5b81db2a9bad966e5/images/page/services/devops/her
o-images/index-hero.jpg)
Result:
The path to the image file can be a relative path or the absolute path in Git or TFVC, just like the path to another
Markdown file in a link.
Relative path: ![Image alt text](./image.png)
Absolute path in Git: ![Image alt text](/media/markdown-guidance/image.png)
Absolute path in TFVC: ![Image alt text]($/project/folder/media/markdown-guidance/image.png)
Resize image: IMAGE_URL =WIDTHxHEIGHT
NOTE
Be sure to include a space before the equal sign.
Example: ![Image alt text]($/project/folder/media/markdown-guidance/image.png =500x250)
It's also possible to specify only the WIDTH by leaving out the HEIGHT value: IMAGE_URL =WIDTHx
Checklist or task list

Supported in: Pull Requests | Wikis
Lightweight task lists are great ways to track progress on your to-dos as a pull request creator or reviewer in the
PR description or in a wiki page. Select the Markdown toolbar to get started or apply the format to selected text.
You can Use [ ] or [x] to support checklists. Precede the checklist with either -<space> or 1.<space> (any
numeral).
Example - Apply the task list Markdown to a highlighted list
After you've added a task list, you can check the boxes to mark items as completed. These actions are expressed
and stored within the comment as [ ] and [x] in Markdown.
Example - Format a list as a task list

- [ ] A
- [ ] B
- [ ] C
- [x] A
- [x] B
- [x] C
Result:
NOTE
A checklist within a table cell isn't supported.
Emoji
In pull request comments and wiki pages, you can use emojis to add character and react to comments in the
request. Enter what you're feeling surrounded by : characters to get a matching emoji in your text. The full set
of emojis are supported.
Example:
:smile:
:angry:
Result:
To escape emojis, enclose them using the ` character.

Example:
`:smile:` `:)` `:angry:`
Result:
:smile: :) :angry:
Ignore or escape Markdown syntax to enter specific or literal

characters
Syntax
Example/notes
To insert one of the following characters, prefix with a \ (backslash).
\ , backslash
` , backtick
_ , underscore
{} , curly braces
[] , square brackets
() , parentheses
# , hash mark
+ , plus sign - , minus sign (hyphen) . , period
! , exclamation mark * , asterisk
Some examples on inserting special characters:

Enter \\ to get \
Enter \_ to get _
Enter \# to get #
Enter \( to get (
Enter \. to get .
Enter \! to get !
Enter \* to get *
Attachments
In pull request comments and wiki pages, you can attach files to illustrate your point or to give more detailed
reasoning behind your suggestions. To attach a file, drag and drop it into the comment field or wiki page edit
experience. You can also select the paperclip in the upper right of the comment box or the format pane in your
wiki page.
If you have an image in your clipboard, you can paste it from the clipboard into the comment box or wiki page
and it renders directly into your comment or wiki page.
Attaching non-image files creates a link to the file in your comment. Update the description text between the
brackets to change the text displayed in the link. Attached image files render directly into your comment or wiki
pages. After you save or update a comment or wiki page with an attachment, you can see the attached image
and select links to download attached files.
Attachments support the following file formats.
TYPE F IL E F O RM AT S
TYPE F IL E F O RM AT S
Code CS (.cs), Extensible Markup Language (.xml), JavaScript

Object Notation (.json), Hypertext Markup Language(.html,
.htm), Layer (.lyr), Windows PowerShell script (.ps1), Roshal
Archive (.rar), Remote Desktop Connection (.rdp), Structured
Query Language (.sql) - Note: Code attachments aren't
permitted in PR comments
Compressed files ZIP (.zip) and GZIP (.gz)
Documents Markdown (.md), Microsoft Office Message (.msg), Microsoft

Project (.mpp), Word (.doc and .docx), Excel (.xls, .xlsx and
.csv), and Powerpoint (.ppt and .pptx), text files (.txt), and
PDFs (.pdf)
Images PNG (.png), GIF (.gif), JPEG (both .jpeg and .jpg), Icons (.ico)
Visio VSD (.vsd and .vsdx)
Video MOV (.mov), MP4 (.mp4)
NOTE
Not all file formats are supported within pull requests, such as Microsoft Office Message (.msg) files.

Both inline and block KaTeX notation is supported in wiki pages and pull requests. The following supported
elements are included:
Symbols
Greek letters
Mathematical operators
Powers and indices
Fractions and binomials
Other KaTeX supported elements
To include mathematical notation, surround the mathematical notation with a $ sign, for inline, and $$ for
block, as shown in the following examples:
NOTE
This feature is supported within Wiki pages and pull requests for TFS 2018.2 or later versions.
Example: Greek characters

$
\alpha, \beta, \gamma, \delta, \epsilon, \zeta, \eta, \theta, \kappa, \lambda, \mu, \nu, \omicron, \pi,
\rho, \sigma, \tau, \upsilon, \phi, ...
$
$\Gamma, \Delta, \Theta, \Lambda, \Xi, \Pi, \Sigma, \Upsilon, \Phi, \Psi, \Omega$
Result:
Example: Algebraic notation
Area of a circle is $\pi r^2$
And, the area of a triangle is:
$$
A_{triangle}=\frac{1}{2}({b}\cdot{h})
$$
Result:
Example: Sums and Integrals
$$
\sum_{i=1}^{10} t_i
$$
$$
\int_0^\infty \mathrm{e}^{-x}\,\mathrm{d}x
$$
Result:
Related articles
README files
Markdown widget
Dashboards
Widget catalog
Add and edit Wiki pages
Markdown syntax for wikis
IMPORTANT
working from Azure DevOps Services or an on-premises version of Azure DevOps Server, renamed from Team Foundation
Server (TFS).
In this article, find some wiki-specific Markdown syntax guidance for use in Azure DevOps.
Table of contents (TOC) for wiki pages

To create a table of contents, add a [[_TOC_]]. The TOC is generated when the tag gets added and there's at least
one heading on the page.
The [[_TOC_]] can be placed anywhere in the page to render the table of contents. Only Markdown headings are
considered for TOC (HTML heading tags aren't considered).
All HTML and Markdown tags get stripped from the headings while adding it inside the TOC block. See the
following example of how the TOC renders when you add bold and italics to a heading.
Consistency is maintained in the formatting in TOC.
NOTE
The tag [[_TOC_]] is case-sensitive. For example, [[_toc_]] may not render the TOC. Also, only the first instance of [[_TOC_]]
is rendered and the rest are ignored.
Add Mermaid diagrams to a wiki page

Mermaid lets you create diagrams and visualizations using text and code.
NOTE
Not all syntax in the content linked below for diagram types works in Azure DevOps. For example, we don't support
most HTML tags, Font Awesome, flowchart syntax ( graph used instead), or LongArrow ----> .
Mermaid isn't supported in the Internet Explorer browser.
If you experience an "Unsupported diagram type", the functionality may not be yet available in your org due to usual
deployment scheme.
Wiki supports the following Mermaid diagram types:

Sequence diagrams
Gantt charts
Flowcharts
Class diagram
State diagram
User journey
Pie chart
Requirements diagram
For more information, see the Mermaid release notes and active requests in the Developer Community.
To add a Mermaid diagram to a wiki page, use the following syntax:
::: mermaid
<mermaid diagram syntax>
:::
Sequence diagram example

A sequence diagram is an interaction diagram that shows how processes operate with one another and in which
order.
::: mermaid
sequenceDiagram
Christie->>Josh: Hello Josh, how are you?
Josh-->>Christie: Great!
Christie->>Josh: See you later!
:::
Gantt chart example

A Gantt chart records each scheduled task as one continuous bar that extends from the left to the right. The x
axis represents time and the y records the different tasks and the order in which they're to be completed.
When you exclude a date, day, or collection of dates specific to a task, the Gantt chart accommodates those
changes by extending an equal number of days toward the right, not by creating a gap inside the task.
::: mermaid
gantt
title A Gantt chart
dateFormat YYYY-MM-DD
excludes 2022-03-16,2022-03-18,2022-03-19
section Section
A task :a1, 2022-03-07, 7d

Another task :after a1 , 5d
:::
Flowchart example
A flowchart is composed of nodes, geometric shapes and edges, and arrows or lines. The following example
shows a flowchart using graph rather than flowchart .
NOTE
We don't support ----> or flowchart syntax, nor links to and from subgraph .
:::mermaid
graph LR;
A[Hard edge] -->|Link text| B(Round edge) --> C{Decision}
C -->|One| D[Result one]
C -->|Two| E[Result two]
:::
Class diagram example

The class diagram is main part of object-oriented modeling. The diagram describes objects, their attributes,
methods, and inheritance between them.
:::mermaid
classDiagram
Creature <|-- Superman
Creature <|-- Vampire
Creature <|-- Diavolo
Creature: +int size
Creature: +int weight
Creature: +isBenign()
Creature: +power()
class Superman{
+String currentName
+fly()
+heal()
}
class Vampire{
-int age
-canBite()
}
class Diavolo{
+bool is_serving
+heat()
}
:::
State diagram example
The state diagram is used to describe how the system states can change from one to another.
:::mermaid
stateDiagram-v2
[*] --> Active
state Active {
[*] --> NumLockOff
NumLockOff --> NumLockOn : EvNumLockPressed
NumLockOn --> NumLockOff : EvNumLockPressed
--
[*] --> CapsLockOff
CapsLockOff --> CapsLockOn : EvCapsLockPressed
CapsLockOn --> CapsLockOff : EvCapsLockPressed
--
[*] --> ScrollLockOff
ScrollLockOff --> ScrollLockOn : EvScrollLockPressed
ScrollLockOn --> ScrollLockOff : EvScrollLockPressed
}
:::
User journey example
The user journey diagram describes what steps are required to complete certain higher level action or task.
:::mermaid
journey
title Home office day
section Go to work
Wake up: 1: Me, Dog
Take shower: 2: Me
Go downstairs: 3: Me, Dog
Make coffee: 4: Me
Have a breakfast: 5: Me, Dog
Go upstairs: 3: Me, Dog
Do work: 1: Me, Dog
section Go home
Go downstairs: 3: Me, Dog
Sit down: 5: Me
:::
Pie chart example

The pie chart diagram is used to visualize the percentages in a circled graph.
:::mermaid
pie title Fishermans in countries
"Norway" : 684
"Sweeden" : 234
"Switzerland" : 10
:::
Requirements diagram example

The requirements diagram visualize the requirements and connections between those.
:::mermaid
requirementDiagram
requirement development_req {
id: 1
text: requirements spec.
risk: medium
verifymethod: test
}
element test_suite {
type: manual test
}
test_suite - verifies -> development_req
:::
Add a collapsible section

To add a collapsible section in a wiki page, use the following syntax:
# A collapsible section with markdown

<details>
<summary>Click to expand!</summary>
## Heading
1. A numbered
2. list
* With some
* Sub bullets
</details>
Make sure to add an empty line in the following areas:
after the closing </summary> tag, otherwise the markdown/code blocks don't show correctly
after the closing </details> tag if you have multiple collapsible sections
Embed videos in a wiki page

To embed videos from YouTube and Microsoft Streams in a wiki page, use the following syntax:
::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/_EXAMPLE_" frameborder="0"
allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::
The IFrame is the embed IFrame block of the YouTube or Microsoft Streams video.
The ending ":::" is required to prevent a break in the page.
Embed Azure Boards query results in wiki

To embed Azure Boards query results in a wiki page as a table, use the following syntax:
::: query-table <queryid>

:::
For example:
::: query-table 6ff7777e-8ca5-4f04-a7f6-9e63737dddf7 :::
You can also use the toolbar and the quer y selector to embed the query results in a wiki page.
For more information about how to copy the query URL, which provides a GUID for the query, see Email query
items or share query URL.
@mention users and groups
To @mention users or groups in wiki, key in "@" in the wiki editor. This @mention opens autosuggest, from
which you can mention users or groups to get notified by email.
You can also select "@mention" from the edit toolbar.
When you're editing pages directly in code, use the following pattern, @<{identity-guid}> .
Page visits for wiki pages

Automatically, you see an aggregated page visits count for the last 30 days on every page.
Use the batch API pagesBatch to see the daily quantity of visits to all pages in a paginated way. They aren't
sorted by number of visits, however. For data over 30 days old, you can get all page visits using the rest API.
Sort these pages based on the number of visits to get the top 100. You can store these visits in a dashboard or
database.
NOTE
A page visit is defined as a page view by a given user in a 15-minute interval.
Link to work items from a wiki page

Enter the pound sign ( # ), and then enter a work item ID.
NOTE
This feature is available with TFS 2018.2 and later versions.
HTML tag support in wiki pages

In wiki pages, you can also create rich content using HTML tags.
TIP
You can nest Markdown within your HTML, but you must include a blank line between the HTML element and the
markdown.

[A Markdown link](https://microsoft.com)

NOTE
Pasting rich content as HTML is supported in Azure DevOps Server 2019.1 and later versions.
Example - Embedded video
<video src="path of the video file" width=400 controls>

</video>
<video src="https://sec.ch9.ms/ch9/7247/7c8ddc1a-348b-4ba9-ab61-51fded6e7247/vstswiki_high.mp4" width=400
controls>
</video>
Result:
Example - Rich text format
This text needs to <del>strikethrough</del> <ins>since it is redundant</ins>!

<tt>This text is teletype text.</tt>
Colored text
<center>This text is center-aligned.</center>
This text contains superscript text.
This text contains subscript text.
The project status is GREEN even though the bug count /
developer may be in red. - Capability of span
Disclaimer: Wiki also supports showing small text
<big>Bigger text</big>
Result:
Related articles
Project wiki
Wiki file structure
Wiki view history
Keyboard shortcuts for managing Wiki pages
NOTE
Keyboard shortcuts for managing Wiki pages are available with TFS 2018.2 and later versions.
You can use the following keyboard shortcuts when managing or editing Wiki pages. To view the valid shortcuts,
enter ? from a Wiki page.
NOTE
The following shortcuts are available from the web portal for TFS 2018.2 and later versions.
n Add new page

e Edit page
c Create new sub-page
Ctrl+↓ Move page down the order
Ctrl+↑ Move page up the order
Ctrl+P Print page
Ctrl+Shift+b Create work item from selected text
Ctrl+b Bold text
Ctrl+i Italicize text
Ctrl+k Insert hyperlink
Ctrl+c Copy text
Ctrl+v Paste copied text
Ctrl+Shift+f Format tables
Ctrl+s Save changes

Ctrl+Enter Save and Close
Esc Close
n Add new page

e Edit page
c Add new sub-page
Ctrl+P Print page
Ctrl+Shift+f Filter page
Ctrl+b Bold text

Ctrl+c Copy text
Ctrl+s Save changes
Esc Close
Related articles
Syntax guidance for Markdown files, widgets, wikis, and pull request comments
Keyboard shortcuts
Default permissions and access set for collaboration
tools
Collaboration tools encompass READMEs, team project Wikis, notifications, feedback, and search.
Most of these tools are available to you if you're added as a team member or a member of the Contributors
group for a team project. The most common built-in groups include Readers, Contributors, and Project
Administrators. For a simplified view of all default permissions assigned to built-in groups, see Default
permissions and access.
Stakeholders have limited access to view charts and dashboards. To learn more, see About access levels.
Default permissions per task

O RGA N IZ AT IO N
T EA M O W N ER/ P RO JEC
A DM IN IST RATO R T
TA SK STA K EH O L DERS REA DERS C O N T RIB UTO RS S A DM IN IST RATO R
Set personal ️
✔ ️
✔ ️
✔ ️
✔
notifications or
alerts
Set team ️
✔ ️
✔
notifications or
alerts
Set project-level ️
✔
notifications or
alerts
READMEs See Note 1 ️

✔ ️
✔ ️
✔ ️
✔
View project ️
✔ ️
✔ ️
✔ ️
✔ ️
✔
wikis
View code wikis ️

✔ ️
✔ ️
✔ ️
✔
Provision or ️
✔
create a wiki
Publish code as ️
✔ See Note 2 See Note 2
wiki
View the project ️

✔ ️
✔ ️
✔ ️
✔ ️
✔
page
Edit the project ️

✔
page
O RGA N IZ AT IO N
T EA M O W N ER/ P RO JEC
A DM IN IST RATO R T
TA SK STA K EH O L DERS REA DERS C O N T RIB UTO RS S A DM IN IST RATO R
Navigate using ️
✔ ️
✔ ️
✔ ️
✔ ️
✔
the project
pages
Request ️
✔ ️
✔ ️
✔ ️
✔
feedback
Provide feedback ️
✔ ️
✔ ️
✔ ️
✔ ️
✔
Powerful code ️
✔ ️
✔ ️
✔ ️
✔ ️
✔
search
Powerful work ️
✔ ️
✔ ️
✔ ️
✔ ️
✔
tracking search
Notes
1. Can view project READMEs, but not READMEs defined for a repository.
2. Project Administrators or Team Administrators with contribute permission can publish code as wiki. Project
Administrators have this permission by default.
Manage permissions
To manage permissions for a collaboration tool, see the following articles:
Manage README & Wiki permissions (security)
Set feedback permissions
To manage notifications, see the following articles:
Manage team notifications
NOTE
There are no UI permissions associated with managing notifications. Instead, you can manage them using the TFSSecurity
command line tool.
Related articles
Work across projects
Add a team administrator
Permissions and groups reference
Data protection overview

Azure DevOps Services is a cloud-hosted application for your development projects, from planning through
deployment. Based on the on-premises capabilities, with additional cloud services, we manage your source
code, work items, builds, and tests. Azure DevOps uses platform as a service (PaaS) infrastructure and many
Azure services, including Azure SQL, to deliver a reliable, globally available service for your development
projects.
This article discusses the steps that Microsoft takes to help keep your projects safe, available, secure, and private.
Also, it describes the role you play in keeping your projects safe and secure.
This article is intended for organization administrators and IT professionals who manage their project assets
daily. It will be most useful to individuals who are already familiar with Azure DevOps and want to know more
about how Microsoft protects stored assets in Azure DevOps.
Our commitment
Microsoft helps to ensure that your projects remain safe and secure, without exception. When stored in Azure
DevOps, your projects benefit from multiple layers of security and governance technologies, operational
practices, and compliance policies. We enforce data privacy and integrity both at rest and in transit.
The threats you face boil down to four basic categories: data availability, service availability, service security, and
data privacy. This article explores specific threats within each category, and explains what Azure DevOps does to
address them. First, the article describes how data is stored and how Azure DevOps manages access to your
data.
Data protection requires active engagement of administrators and users, who must know what steps to take to
protect your assets from unauthorized disclosure and tampering. Be explicit when you grant permissions to user
access points, so only the right people are accessing data within Azure DevOps.
Whatever your approach, you should consider all data potentially "at risk," no matter where it is or how it's
being used. This is true for both data in the cloud and data stored in a private data center. It's important to
classify your data, its sensitivity and risk, and the damage it might do if it becomes compromised. Also,
categorize your data relative to an overall information security management policy.
Built on Azure
We host Azure DevOps entirely in Azure data centers. Azure DevOps uses many core Azure services, including
compute, storage, networking, Azure SQL, identity and access management, and Azure Service Bus.
Azure DevOps uses Azure Storage as the primary repository for service metadata and customer data.
Depending on the type of data and the storage and retrieval needs, Azure DevOps uses Azure Blob Storage (for
binary large objects) and Azure SQL data storage. To understand the Azure DevOps Services approach to data
protection, some background on these elements is important.
Azure Blob Storage stores large chunks of unstructured data. All projects use the Azure Blob Storage
service. Data includes potentially sensitive or private information, like the contents of source files and
attachments for work items. For most projects, the majority of storage in use is this type of unstructured
blob storage. For more information, see Azure Blob Storage.
Azure SQL Database storage stores the structured and transactional aspects of your organization,
including project metadata, the versioned source control history, and work item details. Database storage
gives you fast access to the important elements of your project, and provides indexes into the blob
storage to look up files and attachments. For more information, see Azure SQL Database.
Administrators can manage access to resources by granting or restricting permissions on user identities or
groups. Azure DevOps uses federated authentication of user identities via Azure Active Directory (Azure AD) and
Microsoft accounts.
During authentication, the user is routed to the authentication provider, where they provide their credentials.
After the authentication provider has verified the user's credentials, Azure DevOps issues an authentication
cookie to the user, which allows the user to remain authenticated against Azure DevOps.
In this way, the user's credential information is never shared directly with Azure DevOps. For each Azure DevOps
resource that the user attempts to access, permissions are validated based on the user's explicit permissions, as
well as permissions inherited through group membership. Administrators can use access controls to protect
access to the organization, project collections, team projects, and team-scoped data and functionality.
Administrators can also protect more specific assets like version control folders and work item area paths.
Data availability
Azure DevOps uses many Azure Storage features to ensure data availability if there's a hardware failure, service
disruption, or region disaster. Also, the Azure DevOps team follows procedures to protect data from accidental
or malicious deletion.
Data redundancy
To protect data during hardware or service failures, Azure Storage geo-replicates customer data between two
regions in the same geography. For example, Azure can geo-replicate data between North and West Europe or
between North and South United States.
For Azure Blob Storage, customer data gets replicated three times within a single region, and is replicated
asynchronously to a second region in the same geography. As such, Azure always maintains the equivalent of six
copies of your data. This enables you to fail over to a separate region if there's a major outage or disaster, while
also having local redundancy for hardware failures within a region. For Azure SQL Database storage, daily
backups are maintained offsite if there's a regional disaster.
NOTE
Regarding data redundancy and failover:
There's an inherent delta, measured in minutes, when Microsoft replicates your data between the primary and
secondary region.
Failover to the secondary region is a decision that Microsoft must make centrally, as it affects all customers on the
affected scale unit. Except in extreme circumstances, Microsoft opts to not fail over so that customer data isn't lost.
Azure DevOps offers a 99.9 percent uptime SLA guarantee, and refunds a portion of the monthly charges if that SLA
is missed in a specific month.
Because there is only one region in Brazil, customer data in Brazil is replicated to the South Central US region for
disaster recovery purposes.
Mistakes happen
To protect against accidental deletion of data, Microsoft also takes point-in-time backups of both the blobs in
Azure Blob Storage, and the databases in Azure SQL Database. There's a separate copy of all blobs, and changes
are appended to each storage account. Because this data is immutable, you don't need to rewrite any existing
storage as part of the backup procedures.
Backups are a standard part of Azure SQL Database, and Azure DevOps makes use of this. We maintain 28 days'
worth of your data. In both cases, these backups are also replicated in a paired region, helping to ensure that we
recover from a regional outage.
A further protection is that customers can recover their deleted organizations or projects for up to 28 days after
deletion. Deleted organizations and projects are in a "soft deleted" stage for 28 days allowing customers to
recover as needed. After 28 days they are permanently deleted and cannot be restored.
IMPORTANT
Accidental deletion here refers to scenarios that arise as a result of an incident on our services and doesn't include
accidental deletion of assets (e.g., repositories, work items, attachments, artifacts) by customers. We do not support
restoring assets that are accidently deleted by customers as these backups are meant for business continuity and aid
recovery from outage or disaster scenarios only.
Practice is critical
Having multiple, redundant backups of your data is good but without practice, restoring can be unpredictable.
It's been said that "backups never fail, the restores do." While technically incorrect, the sentiment is right.
Microsoft regularly practices restoring various datasets from backup. Geo-redundant storage from Azure is
tested regularly. Also, from time to time, we restore from backups to recover from human error, such as when a
customer has inadvertently deleted a project in Azure DevOps. There are many combinations of disaster and
data corruption scenarios, which we continue to plan and run new tests for regularly.
Service availability
Azure DevOps offers distributed denial-of-service (DDoS) protections and live site response to help ensure that
you have access to your organization and associated assets.
DDoS protections
In some cases, a malicious DDoS attack can affect service availability. Azure has a DDoS defense system that
helps prevent attacks against our service. It uses standard detection and mitigation techniques such as SYN
cookies, rate limiting, and connection limits. The system is designed to withstand attacks not only from the
outside but also from within Azure.
For application-specific attacks that can penetrate the Azure defense systems, Azure DevOps establishes
application and organization level quotas and throttling. This helps prevent any overuse of key service resources
during an attack or accidental misuse of resources.
Live site response
In rare circumstances, you might require a live site response to a problem with service availability. We have an
operations team available 24x7, to rapidly identify the issue and to engage the necessary development team
resources. Those resources then address the problem. They also aim to update the service status page within
minutes of detecting an issue that affects the service. After the team has addressed an issue, they identify the
root cause of the issue and track the necessary changes to prevent similar issues in the future.
Azure DevOps live site management processes focus on your experience and the health of your service. These
processes minimize the time to detect, respond to, and mitigate problems. All engineering disciplines are
involved and responsible, so there are continual improvements evolving out of direct experience. This means
that monitoring, diagnostics, resiliency, and quality assurance processes improve over time.
Live site management in Azure DevOps has three distinct tracks: telemetry, incident management, and live site
review. Here's what these tracks entail:
The operations team also monitors the availability metrics for individual organizations. These metrics provide
insights into specific conditions that might affect only some of our customers. Investigations into this data can
often result in targeted improvements to address customer-specific issues. In some cases, Microsoft might even
contact you directly to understand your experience and work with you to improve the service.
Microsoft publishes a service-level agreement (SLA) and provides a financial guarantee to ensure that we meet
this agreement each month. For more information, see SLA for Azure DevOps.
Sometimes partner teams or dependencies have incidents that affect Azure DevOps. All partner teams follow
similar approaches to identifying, resolving, and learning from these service outages.
Service security
Service security requires constant vigilance, from proper design and coding techniques to operational factors.
Microsoft actively invests in the prevention of security holes and in breach detection. If there's a breach,
Microsoft uses security response plans to minimize data leakage, loss, or corruption. For more information, see
About security, authentication, and authorization.
Secure by design
Azure DevOps is designed to be secure. Azure DevOps uses the Microsoft Security Development Lifecycle at the
core of its development process. The Microsoft Operational Security Assurance program guides its cloud
operation procedures. The following methodologies specify the following requirements:
Threat modeling during service design.
Following design and code best practices.
Verifying security with standard tooling and testing.
Limiting access to operational and customer data.
Gating rollout of new features through a rigid approval process.
The Azure DevOps team has annual training requirements for all engineers and operations personnel, and
sponsors informal "brown bag" meetings hosted by Microsoft engineers. After they've solved an issue raised in
a brown bag meeting, they share what they learned with the rest of the team.
A cloud service is only as secure as the host platform. Azure DevOps uses PaaS for much of its infrastructure.
PaaS automatically provides regular updates for known security vulnerabilities. VMs hosted in Azure use
infrastructure as a service (IaaS), such as for a hosted build service. Such images receive regular updates to
include the latest security patches available from Windows Update. The same update rigor applies for on-
premises machines, including those used for deployment, monitoring, and reporting.
The Azure DevOps team conducts regular, security-focused penetration testing of Azure DevOps. Using the
same techniques and mechanisms as malicious attackers, penetration testing tries to exploit the live production
services and infrastructure of Azure DevOps. The goal is to identify real-world vulnerabilities, configurations,
errors, or other security gaps in a controlled process. The team reviews the results to identify other areas of
improvement and to increase the quality of the preventative systems and training. You can review the results of
recent Azure DevOps penetration tests on the Service Trust Portal.
Credential security
Your credentials in Azure DevOps are stored using industry best practices. Learn more about credential storage.
Reporting security issues
If during your penetration testing you believe you've discovered a potential security flaw related to the Azure
DevOps service, report it to Microsoft within 24 hours. For more information, see Report a computer security
vulnerability.
IMPORTANT
Although notifying Microsoft of penetration testing activities is no longer required, you must still comply with the
Microsoft Cloud Unified Penetration Testing Rules of Engagement.
Bounty program
Azure DevOps participates in the Microsoft Online Services Bounty Program. This program rewards security
researchers who report issues to us, and encourages more people to help keep Azure DevOps secure. For more
information, see the Azure DevOps Bounty Program.
Restricting access
Microsoft maintains strict control over who gets access to our production environment and customer data.
Access gets granted at the level of least privilege that's required and only after proper justifications get provided
and verified. If a team member needs access to resolve an urgent issue or deploy a configuration change, they
must apply for "just-in-time" access to the production service. Access is revoked as soon as the situation is
resolved.
Access requests and approvals get tracked and monitored in a separate system. All access to the system
correlates against these approvals and if we detect unapproved access, the operations team gets alerted to
investigate.
We use two-factor authentication for all remote system access. So, if the username and password for one of our
developers or operation staff got stolen, the data remains protected. This means additional authentication
checks via smart card or a phone call to a pre-approved number must occur before any remote access to the
service is permitted.
In addition, Microsoft uses secrets to manage and maintain the service, such as RDP passwords, SSL certificates,
and encryption keys. These are all managed, stored, and transmitted securely through the Azure portal. Any
access to these secrets requires specific permission, which is logged and recorded in a secure manner. All secrets
are rotated on a regular cadence, and can be rotated on-demand if there's a security event.
The Azure DevOps operations team uses hardened administrator workstations to manage the service. These
machines run a minimal number of applications and operate in a logically segmented environment. Operations
team members must provide specific credentials with two-factor authentication to access the workstations. All
access is monitored and securely logged. To isolate the service from outside tampering, we don't permit
applications such as Outlook and Office, as they're often targets of spear-phishing and other types of attacks.
Intrusion protection and response
We encrypt data via HTTPS and SSL to ensure it isn't intercepted or modified while in transit between you and
Azure DevOps.
Also, data we store on your behalf in Azure DevOps gets encrypted as follows:
Data stored in Azure SQL databases gets encrypted using Transparent Data Encryption (TDE). TDE
protects against the threat of malicious activity by doing real-time encryption of the database, associated
backups, and transaction log files at rest.
Azure Blob Storage connections get encrypted to protect your data in transit. To protect data at rest
stored in Azure Blob Storage, Azure DevOps uses Azure Storage Service Encryption (SSE).
The Azure infrastructure helps the Azure DevOps team to log and monitor key aspects of the service. This helps
ensure that activities within the service are legitimate, and detects breaches or attempted breaches. In addition,
all deployment and administrator activities are securely logged, as is operator access to production storage.
Real-time alerts are raised because the log information is automatically analyzed to uncover potentially
malicious or unauthorized behavior.
Where a possible intrusion or high priority security vulnerability gets identified, the team has a clear response
plan. This plan outlines responsible parties, steps required to secure customer data, and how to engage with
security experts at Microsoft. The team also notifies any organization owners if data was disclosed or corrupted,
so that they can take appropriate steps to remedy the situation.
Finally, to help combat emerging threats, Azure DevOps employs an "Assume Breach" strategy. A highly
specialized group of security experts within Microsoft, known as the Red Team, assumes the role of sophisticated
adversaries. This team tests breach detection and response, to accurately measure readiness and the impacts of
real-world attacks. This strategy strengthens threat detection, response, and defense of the service. It also allows
the team to validate and improve the effectiveness of the entire security program.
Data privacy
You should have confidence that your data is being handled appropriately and for legitimate uses. Part of that
assurance involves appropriately restricting usage so that your data is used only for legitimate reasons.
General Data Protection Regulation (GDPR )
The General Data Protection Regulation (GDPR) is the biggest change in data protection laws in Europe since the
1995 introduction of the European Union (EU) Data Protection Directive 95/46/EC. For more information about
the GDPR regulation, see the overview page in the Microsoft Trust Center.
Data residency and sovereignty
Azure DevOps is available in the following eight geographies across the world: United States, Canada, Europe,
United Kingdom, India, Australia, Asia Pacific, and Brazil. By default, your organization is assigned to your closest
geography, but you do have the option to choose a different geography. If you change your mind later, it's
possible to migrate your organization to a different geography, with the assistance of Microsoft support.
Azure DevOps doesn't move or replicate customer data outside of the chosen geography. Instead, your data is
geo-replicated to a second region within the same geography. The only exception is Brazil, which replicates data
to the South Central US geography for disaster recovery purposes.
NOTE
For builds and releases running on Microsoft-provided macOS agents, your data will be transferred to a GitHub data
center in the US.
To learn more, see Azure DevOps data location.

Law enforcement access
In some cases, third parties such as law enforcement entities might approach Microsoft to obtain access to
customer data stored within Azure DevOps. We attempt to redirect the requests to the organization owner for
resolution. When compelled by court order to disclose customer data to a third party, Microsoft makes a
reasonable effort to notify the organization owner in advance, unless we’re legally prohibited from doing so.
Some customers require their data storage in a particular geographic location to ensure a specific legal
jurisdiction for any law enforcement activities. All customer data, such as source code, work items, test results,
and geo-redundant mirrors and offsite backups, get maintained within one of the previously mentioned
geographies.
Microsoft access
From time to time, Microsoft employees need to obtain access to customer data stored within Azure DevOps. As
a precaution, all employees who have or might ever have access to customer data must pass a background
check, which verifies previous employment and criminal convictions. We permit access to the production
systems only when there's a live site incident or other approved maintenance activity, which gets logged and
monitored.
Because not all data within our system gets treated the same, we classify data to distinguish between the
following data types:
Customer data - what you upload to Azure DevOps.
Organization data - information used when you sign up for or administer your organization.
Microsoft data - information required for or collected through the operation of the service.
Based on the classification, we control usage scenarios, geo-location requirements, access restrictions, and
retention requirements.
Microsoft promotional use
Microsoft occasionally wants to contact customers to let them know about additional features and services that
might be useful. Because not all customers want to be contacted about these offers, you can opt in and opt out
of marketing email communications.
Microsoft never uses customer data to target specific offers for specific users or organizations. Instead, we use
organization data and aggregate usage statistics at the organization level to determine groups that should
receive specific offers.
Building confidence
You can be confident in other efforts Microsoft makes on behalf of Azure DevOps. These efforts include internal
adoption policies at Microsoft, the level of transparency provided into the state of our service, and progress
towards receiving certification of our information security management systems.
Internal adoption
Teams across Microsoft are adopting Azure DevOps internally. The Azure DevOps team moved into an
organization in 2014 and uses it extensively. More broadly, we have established guidelines to enable the
adoption plans for other teams.
Obviously, large teams move more gradually than smaller ones, given their investments in existing DevOps
systems. For teams able to move quickly, we have established a project classification approach. It assesses risk
tolerance, based on project characteristics, to determine if the project is appropriate for Azure DevOps. For
larger teams, the adoption typically occurs in phases, with more planning.
Additional requirements for internal projects include associating the organization with Azure AD to ensure
proper user identity life cycle and password complexity. For more sensitive projects, two-factor authentication is
also required.
Compliance certifications
Some of you want to understand third-party evaluation of our data security procedures. Azure DevOps has
achieved the following certifications:
ISO 27001:2013
ISO 27018:2019
HIPAA (Health Insurance Portability and Accountability Act)
BAA (Business Associate Agreement)
EU Model Clauses
SOC 1 Type 2
SOC 2 Type 2
Germany C5
The SOC audit for Azure DevOps covers controls for data security, availability, processing integrity, and
confidentiality. The SOC reports for Azure DevOps are available through the Microsoft Service Trust Portal.
Steps you can take

Proper data protection requires your active engagement, as well as that of your administrators and users. Your
project data stored within Azure DevOps is only as secure as the end-user access points. Match the level of
permission strictness and granularity for those organizations with your project's sensitivity level.
Classify your data
The first step is to classify your data. Classify data based on sensitivity and risk horizon, and the damage that
might occur if it gets compromised. Many enterprises have existing classification methods that can be reused
when projects move to Azure DevOps. For more information, you can download the "Data classification for
cloud readiness" document from Microsoft Trustworthy Computing.
Adopt Azure Active Directory
Use Azure Active Directory (Azure AD) to manage your organization's access to Azure DevOps. Azure AD
provides another way to improve the security of your users' credentials. Azure AD allows your IT department to
manage its end-user access policy, password complexity, password refreshes, and expiration if the user leaves
your organization. Through Active Directory federation, you can directly link Azure AD to your organization's
central directory, so you have only one location to manage these details for your enterprise.
The following table compares Microsoft account and Azure AD characteristics relative to Azure DevOps access:
P RO P ERT IES M IC RO SO F T A C C O UN T A Z URE A D
Identity creator User Organization
Single username / password for all No Yes

work assets
Password lifetime & complexity control User Organization
Azure DevOps membership limits Any Microsoft account (MSA) Organization's directory
Traceable identity No Yes
Organization & IP ownership Unclear Organization
Two-factor authentication enrollment User Organization
Device-based conditional access No Organization
Learn more about configuring this support for your organization.

Require two -factor authentication
You might want to restrict access to your organization by requiring more than one factor to sign in. You can
require multiple factors with Azure AD. For example, you can require phone authentication, in addition to a
username and password, for all authentication requests.
Use BitLocker
For sensitive projects, you can use BitLocker on your Windows laptop or desktop computer. BitLocker encrypts
the entire drive on which Windows and your data reside. When BitLocker is enabled, it automatically encrypts
any file you save on that drive. If your laptop or desktop machine falls into the wrong hands, BitLocker prevents
unauthorized access of local copies of data from your projects.
Limit use of alternate authentication credentials
The default authentication mechanism for Git-related tooling is alternate authentication (sometimes referred to
as basic authentication). This mechanism allows the end user to set up an alternate username and password for
use during Git command-line operations. This username and password combination can also be used to access
any other data for which that user has permissions. By its nature, alternate authentication credentials are less
secure than the default federated authentication.
You can still make choices for increased security. All communication gets sent over HTTPS, and there are
password complexity requirements. Your organization should continue to evaluate whether additional policies
are required to meet your project security requirements. You can disable alternate authentication credentials
altogether if you decide that it doesn't meet your organization's security requirements. For more information,
see Change application connection & security policies for your organization.
Secure access to your organization
Azure AD provides the ability for administrators to control access to Azure resources and applications such as
Azure DevOps. With conditional access control in place, Azure AD checks for the specific conditions you set for a
user to access an application. After access requirements are met, the user is authenticated and can access the
application.
Azure DevOps supports enforcing certain types of conditional access policies (for example, IP fencing) for
custom Azure DevOps authentication mechanisms. These mechanisms include personal access tokens, alternate
authentication, OAuth, and SSH keys. If your users are accessing Azure DevOps through a third-party client, only
IP-based policies (IPv4 based only) are honored.
Additional resources
Azure DevOps home page
Azure DevOps data location
Microsoft privacy statement
Azure DevOps support
Features and services included with Azure DevOps
Azure trust center
Microsoft Security Development Lifecycle
You can quickly find work items, code files, wiki pages, or packages based on a keyword, wildcards, and other
supported search filters with the search function.
Take an at-a-glance look at all of the search features further in this article.
Prerequisites
Every project member can use the search functions, including project members granted Stakeholder, Basic,
and higher levels of access.
When searching across the organization or collection, only results for which a project member has access are
listed.
Stakeholder wiki search results are limited to provisioned wikis. Because published wikis require access to
regular repositories, which Stakeholders don't have access to, results for published wikis don't appear in the
search results. Similarly, Code search results don't appear for Stakeholders.
IMPORTANT
For Code search, a Collection Administrator must Install and configure search.
Start your search with a keyword

Start your search using a keyword. You can then apply other options, as needed, to broaden or narrow your
search results.
If you get no results matching the input, try removing filters and retry the search. Broadening the search and
after you view the search results, you can apply appropriate filters again and search again for relevant
results.
Check for the spelling of your search terms. Currently Work item search doesn't support ignoring of users'
spelling mistakes.
If there are lots of hits when you're using a wildcard search, such as when you're using a simple wildcard
search string, you may see a message that no matching files are found. In this case, narrow your search to
reduce the number of matches. Specify more characters of the word or words that you want to find, or add a
condition or filter to limit the number of possible matches.
Searches aren't case-sensitive.
Search features, usage, and examples

The following features apply to all searches, including work items, code, wikis, and packages.
The following features apply to all searches, including work items, code, and packages.
Search feature
Usage
Example
Keyword
Search based on one or more keywords.
validate finds instances that contain the word validate.
Exact match
Search based on an exact match, enclosed in double-quotes.
"Client not found" finds instances that contain the exact phrase match Client not found.
Wildcard
Add wildcard characters, * and ? , to keywords to extend the search criteria.
Add * at the end of a keyword to find items that start with the keyword.
Add ? in the middle to represent any alphanumeric character.
Use wildcard characters anywhere in your search string except as a prefix. You can use prefix wildcards with
the other search filter functions.
You can use more than one wildcard to match more than one character.
alpha?version finds instances of alpha1version and alphaXversion.
Browser* finds instances of BrowserEdge, BrowserIE, and BrowserFirefox.
CodeSenseHttp* finds files containing words that start with CodeSenseHttp, such
as CodeSenseHttpClient and CodeSenseHttpClientTest.
Boolean operators
Find two or more keywords using Boolean operators: AND , OR , and NOT (must be uppercase).
Add parenthesis to clauses to support logical groupings.
Because AND is the default operator, an entry of two keywords with no operator is the same as an AND
search.
Validate AND revisit finds files that contain both the words validate and revisit.
Validate OR revisit finds files that contain either of the words validate or revisit.
Validate NOT revisit finds files that contain the word validate but not the word revisit.
(Validate NOT revisit) OR "release delayed" finds files that contain the word validate but not the
word revisit or files that contain the phrase release delayed.
Proximity
Search for files based on vicinity using proximity operators: NEAR, BEFORE, and AFTER (must be uppercase).
By default, proximity search looks for terms within five tokens distance.
term1 BEFORE term2 returns all files where term1 occurs BEFORE term2 within a distance of five tokens
between them.
term1 AFTER term2 returns the same results as term2 BEFORE term1.
term1 NEAR term2 returns all files where term1 is within five token distance from term2 in any direction.
term1 NEAR term2 returns the same results as term1 BEFORE term2 OR term2 BEFORE term1 .
Special characters
Escape the special characters ( , ) , [ , ] , : , * , and ? by enclosing them in a phrase delimited with
double-quotes.
Include special characters in a search string, or search specifically for special characters, according to the
following rules:
CodeA23?R finds files containing words that start with CodeA23
Have any alphanumeric character next, and end with R. For example, CodeA234R and CodeA23QR.
Search for any special character that isn't a part of the query language.
"flatten()" finds the literal string flatten(). Search for a literal occurrence of the double-quote character " by
preceding it with the escape character \ and enclosing the search string in double-quotes.
"\"react-redux\"" finds the literal string "react-redux".
Search from a different page

You can search from any of the following pages:
The Projects page for the organization: starts a search across all projects.
The Project overview page: automatically applies a filter to search within the selected project.
The Boards page for a project: automatically displays recent work items and backlogs accessed by the user.
Azure Repos, Pipelines, Test Plans, or an Artifacts page for a project: automatically displays functional filters
for code searches.
The wiki page for a project: automatically go to a wiki page you recently opened.
TIP
Use the content type filter to access a page that you recently accessed.
For more information about searching and filtering in Azure Boards, see Filter backlogs, boards, and plans.
For more information about searching wikis, see Provisioned vs. published wiki.
TIP
No results found for ...
If there's a large number of hits when using a wildcard search, such as when using a very simple wildcard search string,
you may see a message that no matching files were found. In this case, narrow your search to reduce the number of
matches. For example, specify more characters of the word(s) you want to find, or add a condition or filter to limit the
number of possible matches.
Additional search functions
To search for various settings, users, projects, and more, see the following table for other types of search tasks
and corresponding actions.
Search task
Action
Find an organization setting

Go to your organization and select Organization settings .
Find a project setting

Go to your project and select Project settings .
Find a user setting

Go to your User settings page .
Find a user
Go to your organization and select Organization settings > Users , and then enter the name in the filter box.
Find an organization
Scroll through the left side of your screen, which lists all organizations.
Find a project
Go to your organization, and then enter the project name in the Filter projects box.
View file history and compare versions

Go to Repos > Files , highlight your file, and then select Histor y .
NOTE
When you search from the Organization settings page, your search results include both organization-level and
project-level settings.
Search re-index requirements

database, re-index all your collections.
Marketplace extensions
Code search - Extends search with fast, flexible, and precise search results across all your code. Required for
searching repositories.
Azure Paths Search - Adds a special search hub to Boards for searching within iterations and area paths
without having to create and maintain custom queries.
NOTE
Some extensions aren't supported features of Azure DevOps and therefore aren't supported by the product team. For
questions, suggestions, or issues you have when using these extensions, visit their corresponding extension page on the
Visual Studio Marketplace.
Next steps
Functional work item search or Functional code search or Functional artifact or package search
Related articles
Code search blog posts
Work item search blog posts
Functional code search
Functional code search extends your ability to refine your search across repositories beyond what's documented
in Get started with search. To do code searches, the Code Search Marketplace extension must be installed for
your organization or collection.
Prerequisites
Install Code Search
For more information, see Install and configure search.
To use Code Search, you must have at least Basic access.
Users with Stakeholder access don't have access to code, so they can't search for code.
Users with Stakeholder access for a public project have full access to code, so they can search for code. To
access code in a private project, you must have at least Basic access.
When you're searching across the organization or collection, only results for which a project member has
access are listed.
Code search best practices

Get the results you want even faster by starting with a higher-level search. You can narrow your search by
using project, repository, path, file name, and other filter operators.
When you're not sure of the exact term you're looking for, Use wildcards to widen your search and Boolean
operators to fine-tune it.
Find more information about an item of interest faster and with minimal efforts. When you find an item of
interest, place the cursor on it and use the shortcut menu to quickly search for that text across all your
projects and files.
Easily trace how your code works by using the shortcut menu to search for related items such as definitions
and references – directly from inside a file or from the search results.
Go quickly to the implementation of, for example, an API your code might be taking dependency on by
narrowing down your results to exact code type matches. Use code type filters to search for specific kinds of
code such as:
definitions
references
functions
comments
strings
namespaces, and more.
NOTE
You can't search code in forked repositories.
Functions to find specific types of code
As you enter your search, select functions and keywords from the drop-down list to quickly create your query.
Use the Show more link to display all the available functions and keywords. Mix and match the functions as
required.
You can also select one or a combination of filters from the list in the left column. Again, the Show more link
displays all the available functions and keywords.
Instead, you can enter the functions and parameters directly into the search. The following table shows a list of
functions for selecting specific types or members in your C#, C, C++, Java, and Visual Basic.NET code.
TO F IN D C O DE W H ERE FIN DT H IS A P P EA RS A S A . . . . . . SEA RC H F O R A RGUM EN T A RG: FIN DT H IS
Argument arg: findThis Deprecated in July 2019
Base type basetype: findThis
Calling function caller : findThis Deprecated in July 2019
Class definition or declaration class: findThis
Class declaration classdecl: findThis Merged with class:
Class definition classdef: findThis Merged with class:
Comment comment: findThis
Constructor ctor : findThis Merged with method:
Declaration decl: findThis
Definition def: findThis
Destructor dtor : findThis Merged with method:
Enumerator enum: findThis
Extern extern: findThis Deprecated in July 2019
Field field: findThis
Friend function friend: findThis Deprecated in July 2019
Function func: findThis Merged with method:
Function declaration funcdecl: findThis Merged with method:
Function definition funcdef: findThis Merged with method:
Global global: findThis Deprecated in July 2019

TO F IN D C O DE W H ERE FIN DT H IS A P P EA RS A S A . . . . . . SEA RC H F O R A RGUM EN T A RG: FIN DT H IS
Header header : findThis Deprecated in July 2019
Interface interface: findThis
Macro macro: findThis
Macro definition macrodef: findThis Merged with macro:
Macro reference macroref: findThis Merged with macro:
Method method: findThis
Method declaration methoddecl: findThis Merged with method:
Method definition methoddef: findThis Merged with method:
Namespace namespace: findThis
Property prop: findThis
Reference ref: findThis
String literal strlit: findThis
Struct struct: findThis Merged with type:
Struct declaration structdecl: findThis Merged with type:
Struct definition structdef: findThis Merged with type:
Template argument tmplarg: findThis Deprecated in July 2019
Template specification tmplspec: findThis Deprecated in July 2019
Type type: findThis
Typedef typedef: findThis Merged with type:
Union union: findThis Deprecated in July 2019
Functions to select projects, repositories, paths, and files

Functions make it easy to narrow the search to specified locations, specific types of files within these locations,
or specified filenames. Narrow the search to a specific location using the proj , repo , or path filters. Mix and
match the functions as required.
USA GE EXA M P L E
Find all occurrences of the word QueueJobsNow in the QueueJobsNow proj:Fabrikam

Fabrikam project.
Find all occurrences of the word QueueJobsNow in the QueueJobsNow repo:Contoso

Contoso repository.
Find all occurrences of the word QueueJobsNow in the path QueueJobsNow path:VisualStudio/Services/Framework
VisualStudio/Services/Framework and its subpaths.
Enclose the argument to the filter in double-quotes if it QueueJobsNow path:"VisualStudio/Windows Phones and
contains a space. Devices/Services"
Find all occurrences of the word QueueJobsNow in all files QueueJobsNow file:queueRegister*
where the filename starts with queueRegister.
Find all files with the name QueueRegister without an file:"queueRegister"

extension. Use quotes to find files without extensions.
Find all occurrences of the word QueueJobsNow in only C# QueueJobsNow ext:cs

source files. A plain text search string that doesn't include file
type functions also finds files where the string matches part
of the filename.
Find related items or other terms

One of the powerful features of Code Search is the capability to expand your search interactively, based on the
results of previous searches. For example, you can easily broaden your search to related files when tracing or
debugging code.
Place the insertion point on a term in the file and open the shortcut menu (mouse: right-click) to start a new
search for other files containing the selected term. You can search for it as text, for the definition if you select an
object name, or for references to a selected object.
For more information about the following search functions, see Get started with search.
Keyword
Exact match
Wildcard
Boolean operators
Proximity
More code search operations

See the following examples of even more code search functions. You can use the code type search functions with
files written in C#, C, C++, Java, and Visual Basic.NET. Open the search results in a new browser tab from the
main search box, and select Ctrl + Enter . In Google Chrome, select Ctrl + Shift + Enter to switch the focus to
the new browser tab.
USA GE EXA M P L E
Find all instances of "ToDo" comments in your code Select comment: and enter todo
USA GE EXA M P L E
Search in specific locations, such as within a particular path Use a search string such as
Driver path:MyShuttle/Server
Search for files by name or just by file extension Driver file:GreenCabs.cs . The search string
error ext:resx could be useful if you want to review all
error strings in your code. Even if your plain text search
string matches part of a filename, the file appears in the list
of found files. This search works without matching specific
file type functions.
Search Git projects and repositories

In a Git project, you see a list of the repositories that it contains. Use the project and repository checkboxes to
widen your search. You can search more or all projects, or narrow your search to fewer projects and repositories.
If there are more than a few projects or repositories, use the Show more link to see them all.
Code Search can index multiple branches in a Git repository. By default it indexes files in only the default branch
of your Git repositories. Your default branch is usually the main branch. Specify the branches for each
repository, indexing in the Options tab of the Repositories section, project settings page.
Search TFVC projects

In a TFVC project, you see a list of folder paths in that project for which you have read access - you won't see any
projects and folders for which you don't have read permission. Select paths in the folder tree to narrow your
search if necessary.
TIP
Code Search remembers your last settings, such as the project and repository or path that you searched in. Clear the
checkboxes to search across all projects easily with the Clear all links when you want to search in a different scope. In the
results pane, Code Search highlights up to the first 100 hits or matches found in the target files.
Search code with REST API

You can use APIs to extend or supplement the capabilities listed in this article. For information about Code
Search with REST API, see Fetch Code Search Results.
Next steps
Search work items
Related articles
Search artifacts and packages
Search work items
Search FAQs
Functional work item search
Functional work item search command filters extend your ability to refine your search of work items based on
assignment, work item type, specific fields, and more. This is in addition to the filter functions documented in
Get started with search. Work item search is a built-in feature available to all Azure DevOps users.
You can use Work Item Search by default without any installation when the Boards service is installed and
enabled in Azure DevOps Services.
By using Work Item Search, you can do the following tasks and more.
SEA RC H TA SK DESC RIP T IO N
Search over all your projects Search in your own and your partner teams' backlog. Use
cross-project searches over all the work items to search
across your enterprise's entire work items. Narrow your
search by using project and area path filters.
Search across all work item fields Quickly and easily find relevant work items by searching
across all work item fields, including custom fields. Use a full
text search across all fields to efficiently locate relevant work
items. The snippet view indicates where matches were found.
Search in specific fields Use the quick in-line search filters to narrow down to a list of
work items in seconds. Use the filters on any work item field.
The list of suggestions helps complete your search faster. For
example, a search such as AssignedTo:Chris
WorkItemType:Bug State:Active finds all active bugs
assigned to a user named Chris.
Search across test Search across Test Plans, Test Suites, and other test work
item types.
Take advantage of integration with work item tracking The Work Item Search interface integrates with familiar
controls for managing your work items; letting you view,
edit, comment, share, and more.
Prerequisites
All users can use work item search.
Search by work item ID
Enter the work item ID in the Azure DevOps title bar to quickly go to it. Searching for a work item ID opens the
work item in a modal dialog, providing quick access to read and edit work items.
Full text search across all fields
You can easily search across all work item fields, including custom fields, which enables more natural searches.
The snippet view indicates where matches were found.
Use simple search strings for words or phrases. Work item search matches derived forms of your search
terms; for example, a search for "updating" also finds instances of the word "updated" and "update". Searches
aren't case-sensitive.
When you search from inside a project, the default is to search only within that project.
While searching from inside a team, the default is to search only within the default area path of that team.
When you have one project selected, you see a list of area paths in that project for which you have
read access - you won't see any projects and area paths for which you don't have read permission
Select area paths in the tree to narrow your search if necessary.
The selected projects are always at the top of the list. Notice that hit counts are also shown for projects that
aren't selected.
Open the search results in a new browser tab from either the main search function or by selecting Ctrl +
Shift + Enter .
Work item search best practices

Use a text search across all fields to efficiently locate relevant work items. Text search is useful when you're
trying to, for example, search for all work items that had similar exception trace.
Use the quick in-line search filters on any work item field to narrow down to a list of work items in seconds.
The list of suggestions helps complete your search faster.
Search vs. managed work item queries

You have two ways to find and list work items: managed queries and the main search function. If you're looking
for a single work item, use the main search. If you want to generate a list of work items to triage, update, chart,
or share with others, use a managed query.
With the main search function, you can search against a more fully indexed set of fields than that of managed
queries.
Use a managed quer y

Search
List items to perform bulk updates to fields.

Review work that's in progress or recently closed.
Triage work: set priority, review, update.
Create a chart and add it to a dashboard.
Create a chart to get a count of items or sum a field.
Create a chart that shows a burndown or burnup over time.
View a tree of parent-child related work items.
List work items with link relationships.
List work items for a single project, multiple projects, or across all projects.
Find a specific work item using its ID or a keyword.
Find one or more work items across all projects in a fast, flexible manner.
Perform full text search across all work item fields.
Review work items assigned to a specific team member.
Search against specific work item fields to quickly narrow down a list of work items.
Determine what key words will support a managed search.
List work items for a single project, multiple projects, or across all projects.
To get started, see the following articles:

View and run a query
Use search
Define a query
For specific managed query examples, see Query quick reference, Example queries.
Apply supported functions to work item search

1. Fine-tune your search by specifying the fields to search. Enter a: and a user name to search for all items
assigned to that user.
See the following quick filters that you can use:

a: for Assigned to:
c: for Created by:
s: for State
t: for Work item type
2. Start entering the name of a field in your work items; for example, enter ta .
The dropdown list shows work item field name suggestions that match user input. These suggestions
help you complete the search faster. For example, a search such as tags:Critical finds all work items
tagged 'Critical'.
3. Add more filters to further narrow your search, and use Boolean operators to combine terms if necessary.
For example, a: Chris t: Bug s: Active finds all active bugs assigned to a user named Chris.
4. Narrow your search to specific types and states, by using the selector lists at the top of the results page.
5. Widen your search across all projects, or narrow it to specific types and states. Use the filter to show the
selector lists.
6. Select the criteria you want in the drop-down selector lists, or search across the entire organization.
7. Sort the results as you need using the drop-down list of field names, work item types, or by relevance.
1. Fine-tune your search by specifying the fields to search. Enter a: and a user name to search for all items
assigned to that user.
See the following quick filters that you can use:

a: for Assigned to:
c: for Created by:
s: for State
t: for Work item type
2. Start entering the name of a field in your work items; for example, enter ta .
The dropdown list shows work item field name suggestions that match user input. These suggestions
help you complete the search faster. For example, a search such as tags:Critical finds all work items
tagged 'Critical'.
3. Add more filters to further narrow your search, and use Boolean operators to combine terms if necessary.
For example, a: Chris t: Bug s: Active finds all active bugs assigned to a user named Chris.
4. Narrow your search to specific types and states, by using the drop-down selector lists at the top of the
results page.
5. Widen your search across all projects, or narrow it to specific types and states. Use the filter to show the
selector lists.
6. Select the criteria you want in the drop-down selector lists, or search across the entire organization.
7. Sort the results as you need using the drop-down list of field names, work item types, or by relevance.
Quick filters for matching in specific fields
Quick inline search filters let you refine work items in seconds. The dropdown list of suggestions helps complete
your search faster. Mix and match the functions to create quick powerful searches.
USA GE EXA M P L E
Scope your search terms to match in any work item field tags:Critical finds work items having a field 'tags'
including custom fields. Enter the field name followed by the containing the term 'Critical'.
search terms.
Use multiple inline search filters to scope your search by any t: Bug path:"project\search" finds all bugs in the area
work item field, including custom fields. path "project\search".
Use the operators > , >= , < , <= , = , and != for date, t: Bug CreatedDate> @Today-7 finds all bugs created in
integer, and float fields. the last week.
For the search query that contains multiple terms and users BuildPath: "tools.demoproject.com" finds all work items
looking for exact match, embed the search term inside " " that necessarily contain the path "tools.demoproject.com".
Scope projects and area and iteration paths using filters
Filters make it easy to narrow the search to specified projects and area paths.
Narrow the search to a specific location using the proj , area , iteration , path , and comment filters:
USA GE EXA M P L E
Finds all occurrences of the word Wiki in the Fabrikam Wiki proj:Fabrikam
project.
Finds all occurrences of the word Wiki in the area path Wiki area:Contoso/Mobile
Contoso/Mobile and its subpaths.
Finds all occurrences of the word Wiki in the iteration path Wiki iteration:Contoso/Sprint101
Contoso/Sprint101 and its subpaths.
Enclose the argument to the filter in double-quotes if it Wiki path:"Contoso/Windows Phones and
contains a space. Devices/Services"
Finds backlog comments comment:todo
See more of the work item

You can quickly get a full screen view of the selected work item using expand and shrink in the toolbar.
However, another way to see more of the work item, while you can still select work items from the list of
matching results, is to hide the left column filter pane by choosing < at the top left of the column. Use > to
restore the filter pane.
If you're using a portrait orientation screen, use the Preview pane: Right link at the top right of the window to
display the code below the search results list.
TIP
Search remembers the state of the filter pane, configuration of the work item view pane, and its position between sessions
as part of your user preferences.
Search Work Items with REST API

You can use APIs to extend or supplement the capabilities listed in this article. For information about Work Item
Search with REST API, see Fetch Work Item Search Results.
Next steps
Supported filter functions and more for work items
Related articles
Search code
Search artifacts and packages
Search FAQs
Search packages across your feeds
Package Search is available to all users of Azure DevOps. For information on main search functions, see Get
started with search.
Prerequisites
Azure DevOps Services account.
Azure Artifacts feed.
Apply supported functions to package search

1. Select the filter icon to show the filter panel.
2. Select from the dropdown menus to search by feeds, views, or package types.
By default, you search within all feeds of the organization, no matter which project you're in. The Views filter
only appears if a single feed gets selected from the Feeds filter. Use this filter to show packages from a specific
view. Using the Type filter, you can select the type of package you want to search for (such as NuGet packages).
Search using the REST API

You can use the Azure DevOps REST API to search for packages in a specific organization. See Fetch Package
Search Results for more details.
NOTE
Searching for packages in upstreams with NuGet Package Explorer is not supported. See Download NuGet packages for
more details.
Next steps
What are feeds? What are feed views? Promote a package to a view
Related articles
Search code
Search work items
Search FAQs
Search organization settings

The preview feature, New Settings Search in the organization settings panel , enables a search box for
searching within Organization Settings . To enable this feature, see Manage or enable preview features.
Perform a search
Enter a keyword to search all settings within your organization. For example, here we search on Notifications .
Search results return findings with links to the settings. Settings include Organization, project, and user.
To navigate to one of the settings listed, choose the card in which it appears.
Keywords
Each setting is tagged with a number of keywords. These keywords capture the level of setting, such as
organization, project, or user, as well as other categories. Entering a keyword with any part of a setting label or
description should return it within the results.
Related articles
About settings
Install and configure Search
Learn how to do the following actions for the Search extension for Code, Wiki, and Work item searches in Azure
DevOps Server.
Configure Search
Secure Search
Upgrade Search
Uninstall Search
For information about managing Search indexing, see Manage Search and indexing.
Prerequisites
To install the Search extension, you must be a Project Collection Administrator (PCA) for the organization.
Non-administrative users can also request that the extension get added to their PCA.
See Install and configure Azure DevOps Server and Requirements and compatibility.
Hardware recommendations
You can use Search on any size physical server or virtual machine that runs Azure DevOps Server. You can
configure it on the same server, or on a separate server dedicated to Search. When you're configuring Search on
the same server, consider the existing CPU utilization factor because of Azure DevOps Server itself.
TIP
For production environments, we recommend you configure Search on a separate server.
For acceptable performance in multi-user scenarios, consider the following recommendations:

Fewer than 250 users with Search located on the server (typically used for demonstration and trial
purposes):
Quad core processor, 16 GB (minimum) RAM
CPU Utilization factor less than 50%
Fast hard drive backed by Solid State Drive (SSD) storage
Fewer than 500 users with Search located on a separate server:
Dual core processor, 8 GB (minimum) RAM
Fewer than 1,000 users with Search located on a separate server:
More than 1,000 users with Search located on a separate server:
Fast hard drive backed by Solid State Drive (SSD) or Storage Area Network (SAN) storage
Azure DevOps Server with Multiple ATs:
Install Search on a separate server
Azure DevOps Server CPU utilization greater than 50% before Search installation:
Install Search on a separate server
Disk space requirement :
The amount of disk space used by Search depends mainly on the type and size of files indexed. For Code search,
since many times repositories can be large and have different code files in version control, disk space
requirement could be significant. Allocate up to 150% of the size of all the repositories to be indexed.
From TFS 2018 Update 3 and onward, users can exclude folders from their repositories for index to optimize the
disk space that's consumed by search.
Software dependencies
Search has the following dependencies, which are installed automatically as part of the configuration:
Elasticsearch by Elasticsearch BV (see Notes 1 and 2)
Elasticsearch NEST client
Azul Zulu OpenJDK (see Java installation notes)
Markdowndeep by Topten Software
Roslyn compiler platform
ANTLR language recognition parser
NOTE
Search uses a modified version of Elasticsearch. It works only with this modified version
A newer version of Elasticsearch ships with TFS 2018 Update 2 and onward, and Azure DevOps Server. All content is
reindexed after installation when you upgrade from an older version of Search results. Depending on the volume of
content (code files, work items, and wiki pages), re-indexing can take some time to complete
The system or server administrator must ensure that Server JRE is maintained and updated in line with the software
provider's recommendations. Also see the Java installation notes that follow
The Azul Zulu OpenJDK doesn't automatically install updates
Ensure that you regularly check for updates
Java installation notes

If the Search configuration wizard doesn't detect a working installation of a Java Runtime Environment (JRE),
it provides an option to download and install the latest supported version. Internet connectivity is required to
download. If the target server doesn't have Internet connectivity, you must download and install a JRE
manually before attempting to install Search.
Versions of Search before Azure DevOps Server used the Oracle Server Java Runtime Environment. In Azure
DevOps Server, the default JRE is Azul Zulu OpenJDK.
During installation, the wizard sets the JAVA_HOME environment variable to point to the JRE installation
folder. The configuration wizard might not detect an existing JRE installation if it wasn't correctly configured,
or if the JAVA_HOME setting points to an earlier version than required by Search.
NOTE
We don't advise installing Elasticsearch on a machine where resources are shared, especially on a large enterprise
environment with multiple application tiers. Instead, we recommend that you set up Elasticsearch in a separate dedicated
machine. In that way, the JAVA environment isn't shared across machines for other purposes.
If there's a version of a JRE earlier than the minimum required by Search, and the JAVA_HOME variable
was set to that version, we recommend that you install Search on a separate server. If you change the
value of the JAVA_HOME variable, it may cause other installed software to fail.
If there's a version of Server JRE equal to or later than the minimum required by Search and it's not
recognized by the configuration wizard, set the value of the JAVA_HOME variable to that version. This
action's described in the JRE installation guide. Then, rerun the configuration wizard.
Zulu OpenJDK installation guide
Oracle JRE troubleshooting guide
If you can't install the version of Java required by Search because of other dependencies, you can do the
following tasks:
Install Azure DevOps Server with the Search extension on a server that doesn't have Java installed. We
don't recommend this action for more than 250 users or CPU utilization greater than 50% or multiple
ATs)
Install Search and the JRE on a separate server from Azure DevOps Server
NOTE
If you're using Oracle Server JRE 8, which was the default for Search in TFS (Azure DevOps Server doesn't use Oracle
Server JRE 8), be aware of the following information:
Search doesn't use or support any of the commercial features of Server JRE 8. Therefore, during Search
configuration,the commercial features of the Server JRE are neither activated nor unlocked
If you choose to continue with Oracle JRE, contact Oracle for a Java SE Subscription, so that you can continue to
receive JRE updates
Migrate to Zulu OpenJDK from Oracle Server JRE

Search in Azure DevOps Server supports both Azul Zulu OpenJDK and Oracle JRE, allowing you to choose
between them based on your needs. When selecting a JRE during installation, Azure DevOps Server defaults to
Azul Zulu OpenJDK 8.
To change to the Azul Zulu OpenJDK, follow these steps:
For more information, see GitHub Code-Search Java Migration.
NOTE
If you choose to use Azul Zulu OpenJDK, ensure that you download version 8.
Feature availability
Work Item Search is available in TFS 2017 Update 2 and later versions.
Wiki Search is available in TFS 2018 Update 2 and later versions.
Work Item and Wiki search are built-in extensions that are installed by default during Search configuration.
Code Search is available in TFS 2017 and later versions, and is an opt-in feature. You can install Code Search
later from the Local Gallery. Go to Local Galler y ( http://{server}/_gallery ) as an administrator. Non-
administrative users can also request the extension for Azure DevOps Server. For more information, see
Install an extension in the Local gallery documentation.
Configure Search
Configure the Search service using the dedicated pages in the Server Configuration Wizard as you install Azure
DevOps Server. You can also un-configure Search afterwards by running the Server Configuration Wizard again
or by launching the Search Configuration Wizard. For configuring Search, be aware of the configuration
considerations.
Configuration considerations
Consider the following information when you're configuring Search:
Both Work Item and Wiki search get enabled by default when Search is configured. These extensions can
be later removed if necessary from the Manage Extensions page of Azure DevOps Server
The Code Search extension must be installed for each Azure DevOps Server collection where you want to
use it. When initially configuring Search, you can set a checkbox to Automatically install Code Search
extension for existing and new Project Collections to automate this process
If you don't set the checkbox to install the Code Search extension for all your project collections, your
PCA can install it from the Local Gallery. Ensure you go to the Local Gallery ( http://{Server}/_gallery
) from your Azure DevOps Server portal page. For more information, see Install an extension in the
Local gallery documentation
Use a second hard drive and remote server
For maximum performance, the search index folder should be on a separate fast hard drive and backed
by fast storage, such as a solid-state drive (SSD) or Storage Area Network (SAN). Allocate up to 150%
of the size of all the repositories to be indexed. That's the worst-case scenario. The actual space that's
consumed depends on the amount and type of code files, and the number of work items and wiki pages
in that collection
Unless specified, the indexing service and Elasticsearch engine use the network service account during
installation to create and access the index files. If you choose a different account, it must have Log on
as a ser vice permission
Restrict the permissions for the index disk and folder to protect the index from accidental or malicious
modification or deletion. Configure appropriate security settings for the service
When you're configuring Search for a server with multiple application tiers (ATs) , make sure it's
installed on a separate server. After you've installed Search on the remote server, use the Configuration
Wizard on any one of the AT servers to link the remote Search instance with your Azure DevOps Server
instance. When un-configuring Search in the future you must use the Configuration Wizard on the same
AT server where configuration was originally carried out
Upgrade your server
If you're doing a pre-production upgrade on a server where Search was already configured, you must
fully reconfigure Search again to avoid corrupting your production instance. There's no option to
configure Search as part of a pre-production upgrade. Instead, configure it after the pre-production
upgrade is complete. You can uncheck Automatically install and configure Code Search for all
existing and new collections during configuration. Instead, install the Search extension for just one or
two of your collections after configuration is complete
If you're doing a production upgrade on a server where Search is configured and you want to keep it,
check the box next to Install and Configure Search . The wizard detects your existing Search instance
and automatically selects Use existing Search instance , and pre-populates your current Search
service URL. Use the Install a new Search instance option only if you want to set up a new instance of
Search on the same server. Setting up a new instance causes all your code, work items, and wiki to be
indexed again, which - depending on the size of the collections - can take some time. During indexing,
users may see partial search results
If you're upgrading your ser ver to new hardware , you have the following two options. Select from
these options, depending on how Search was previously configured:
If Search is on a separate server from Azure DevOps Server, you must select Install and Configure
Search in the Server Configuration Wizard, and then select Use an existing Search instance and
provide the URL of your existing Search instance to complete the Search configuration
If Search is configured alongside your Azure DevOps Server instance on the old server, you must
select Install and Configure Search in the Server Configuration Wizard. Then, select Install a new
Search instance again on the new server if you want to continue to cohost Search and Azure
DevOps Server. All Search indexes for all collections are re-created which, depending on the size of
each collection, might take some time
If you're detaching a collection from one Azure DevOps Server instance to attach it to another
instance, do the following steps:
1. Detach the collection from source Azure DevOps Server instance
2. Configure Search on the target Azure DevOps Server instance (if not yet done already)
3. Attach the collection to the target Azure DevOps Server
4. Uninstall your Search extensions, like Code, Work item, or Wiki for the collection from the Local
Galler y within your Azure DevOps Server
5. Install the Search extension, for the collection from the Local Galler y , by browsing to it from your
target Azure DevOps Server instance
Install or update Search on a separate server
To install or update Search on a separate or remote server, typically when there are more than 250 users, do the
following steps:
1. As you install Azure DevOps Server on the primary server, set the Install and configure Search
checkbox in the Search page of the Server Configuration Wizard.
2. Select the option to Use an existing Search ser vice .
3. Use the Search ser vice package link that's provided in the wizard to access a set of Search installer
files on the local machine. Then, copy these files to the remote server.
4. Follow the instructions in the Readme.txt file, located in the set of installer files, to install or update the
Search service on the remote server.
5. After installation completes, copy the resulting Search server URL into the Search URL field of the
configuration wizard that runs on the Azure DevOps Server instance.
6. When both installations are complete, configure appropriate security settings for both servers.
Secure search
The Search service uses a modified version of Elasticsearch (the terms "Search" and "Elasticsearch" are used
interchangeably for the rest of this section). Administrators must provide credentials whether the Search service
is on the same machine as Azure DevOps Server, or on a separate machine. This action is part of configuring the
Search feature through the server or the Search configuration wizard. These credentials are new and aren't
related to any pre-existing account or server credentials. They're used to set up and connect to Search service.
These new sets of credentials enable basic authentication in the search service.
For an upgrade from TFS 2018 Update 1.1 to TFS 2018 Update 3 or for search reconfiguration, only the user
information autopopulates and administrators must provide password credentials. Administrators have an
option to provide different username and password if they wish. If the Search service is on the same machine as
Azure DevOps Server, administrators can provide a new set of credentials in the Configuration Wizard to set up
the Search service, if wanted. However, if the Search service is on a remote machine, administrators must first
provide the new credentials to the Search service setup script.
NOTE
Username and password values should both be between 8 and 64 characters in length. While the password can be
assigned any value, the username can contain only alphanumeric and underscore characters.
Search credentials only authenticate the users and make sure that unauthenticated users can't access the Elasticsearch
endpoint. However, Elasticsearch doesn't support HTTPS and so these credentials get sent over the network as Base64
encoded strings. If there's a possibility of intermediate access to request, configure appropriate security settings based
on your corporate security and compliance requirements.
Aim to limit access to both searching and indexing to specific users or user groups using encryption through IPSec,
described as follows.
Consider the following techniques for using IPSec to secure Elasticsearch on a Windows server:
Configure security with authentication only:
Ensures only authorized users can access the Elasticsearch port. It requires only service-side rules
(firewall rules on only the server running Elasticsearch)
Prerequisite: Azure DevOps Server must be configured with a domain account
Follow the steps in Creating Firewall Rules that Allow IPsec-protected Network Traffic
Configure security with authentication, integrity protection, and encr yption:
Ensures encryption and integrity protection are applied along with authentication. It requires both
client-side and service-side rules (firewall rules on the server running Elasticsearch and all Azure
DevOps Server App Tier servers)
Prerequisite: Azure DevOps Server must be configured with a domain account
Follow the steps in Isolating a Server by Requiring Encryption and Group Membership
Upgrade search
TFS 2017 Update 1 includes updated Search components.
If the Search service was configured in TFS 2017 RTM during an upgrade, the Search service
components are updated automatically if the Search service was configured on the TFS that's getting
upgraded.
If Search was configured on a remote server, follow the instructions to update it.
TFS 2017 Update 2 includes Work items Search. It uses the same Search service as Code Search.
If the Search service was configured in TFS 2017 RTM/Update1 during an upgrade, the Search service
components get updated automatically if the Search service was configured on the TFS that's being
upgraded.
TFS 2018 Update 2 includes updated Search components and Wiki Search.
If the Search service was configured in TFS 2017 RTM, Update1, Update2, or TFS 2018 RTM during an
upgrade, the Search service components get updated automatically if the Search service was
configured on the TFS that's being upgraded.
In both cases, all existing content (code files and work items) gets automatically reindexed to support the
updated components after configuration. Depending on the volume of content, this upgrade might take
some time to complete.
TFS 2018 Update 1.1 and TFS 2018 Update 3 include basic authentication for the communication
between the TFS and Search service to make it more secure. Any installation or upgrade to TFS 2018
Update 1.1 or TFS 2018 Update 3, must provide credentials as part of configuring Search feature,
through Server or the Search configuration wizard.
TFS 2018 Update 2 (or higher) to version Azure DevOps Ser ver 2019 Update 1 , when search is
configured on a separate server, requires a reinstallation of search. While following the instructions for an
upgrade, in step 4 instead of updating Configure-TFSSearch.ps1 – Operation update , run the following
command to reinstall search:
Configure-TFSSearch.ps1 -Operation remove

Configure-TFSSearch.ps1 -Operation install -TFSSearchInstallPath <install location> -TFSSearchIndexPath
$env:SEARCH_ES_INDEX_PATH
Uninstall Search
For a pre-production upgrade, production upgrade, new hardware migration, cloning, or other maintenance
operation, the Server Configuration Wizard unconfigures Search. But, it's easy to reconfigure after the server
maintenance operation is complete.
However, there might be cases where you no longer want to use Search or you want to do a new and clean
install. This operation requires multiple steps, depending on whether Search is configured on the same server as
Azure DevOps Server, or on a separate server.
Un-configure Search on the machine configured as your Azure DevOps Server

1. Uninstall the Search extension for each collection where it's installed. Go to the Manage Extensions
page of each collection in your Azure DevOps Server instance:
2. Remove the Search feature:

Open the Azure DevOps Server Administration Console
In the left pane, select the name of the server
In the right pane, choose Remove Feature
In the Remove Feature dialog, select Search ser vice , and then choose Remove
3. Remove the Elasticsearch service:
Open Command Prompt as an administrator
Change the directory:
For TFS 2017 RTM,
cd "C:\Program Files\Microsoft Team Foundation Server 15.0\Search\ES\elasticsearch-1.7.1-
SNAPSHOT\bin"
For TFS 2017 Update 1,
cd "C:\Program Files\Microsoft Team Foundation Server 15.0\Search\ES\elasticsearch-
2.4.1\bin"
For TFS 2018 Update 2 and onward, and Azure DevOps Server,
cd "C:\Program Files\Microsoft Team Foundation Server 15.0\Search\ES\elasticsearch-
5.4.1\bin"
Remove the service:
For TFS 2017, "service.bat remove"
For TFS 2018 and Azure DevOps Server, "elasticsearch-service.bat remove"
4. Remove Search data:

Delete the contents of the location described by the environment variable SEARCH_ES_INDEX_PATH
5. Remove environment variables:
Delete the environment variable "SEARCH_ES_INDEX_PATH"
Delete the environment variable "ES_HEAP_SIZE" (this environment variable is obsolete for TFS 2018
Update 2 and later, and Azure DevOps Server)
Un-configure Search when it's configured on a separate server

1. Uninstall the Search extension, like for Code, Work item, or Wiki, for each collection where it's installed.
Go to the Manage Extensions page of each collection in your Azure DevOps Server instance.
2. Remove the Search feature:

Open the In the Remove Feature dialog, Administration Console
In the left pane, select the name of the Azure DevOps Server
In the right pane, choose Remove Feature
In the Remove Feature dialog, select Search ser vice , and then choose Remove
3. Remove the Elasticsearch service and data:
Open PowerShell as an administrator
Open the Configure Search.ps1 folder, along with the rest of the files that are required for a remote
install of Search
Run the script again with the remove option:
For TFS 2017 RTM, "Configure Search.ps1 -RemoveTFSSearch"
For TFS 2017 Update1 and onward, and Azure DevOps Server,
"ConfigureTFSSearch.ps1 -remove"
Search limitations
database, reindex all your collections.
Related articles
Manage indexing for Search
Search FAQs
Web portal navigation in Azure DevOps
The web portal for Azure DevOps is organized around a set of services as well as administrative pages and
several task specific features such as the search box. The service labels differ depending on whether you work
from Azure DevOps Services or Azure DevOps on premises and its version.
IMPORTANT
working from Azure DevOps Services or an on-premises version of Azure DevOps Server.
The web portal for Azure DevOps Server is organized around a set of services—such as, Over view , Boards ,
Repos , Pipelines , Test Plans , and Ar tifacts — as well as administrative pages and several task-specific
features such as the search box. Each service provides you with one or more pages which support a number of
features and functional tasks. Within a page, you may then have a choice of options to select a specific artifact or
add an artifact.
The web portal for Team Foundation Server is organized around a set of applications—such as, Dashboards ,
Code , Work , Build and Release —as well as administrative pages and several task-specific features such as
the search box. Each service provides you with one or more pages which support a number of features and
functional tasks. Within a page, you may then have a choice of options to select a specific artifact or add an
artifact.
Here's what you need to know to get up and running using the web portal.
Open another project or repo : use to switch to a different project or access work items and pull requests
defined in different projects, or items you've favorited
Open team ar tifacts, use breadcrumbs, selectors and directories : use to navigate within a service, to
open other artifacts, or return to a root function
Settings : use to add teams, manage security, and configure other project and organization level resources.
Open another project or repo, or switch to a different team : use to switch to a different project or
browse teams
Work across projects : use to quickly open work assigned to you, your active pull requests, or items you've
favorited
Open team ar tifacts, use breadcrumbs & selectors : use to navigate within a service, to open other
artifacts or return to a root function
Settings : use to add teams, manage security, and configure other project and organization-level resources.
NOTE
service on or off.
You select services —such as Boards , Repos , and Pipelines — from the sidebar and pages within those
services.
You select a service—such as Code , Work , and Build and Release —from the horizontal bar and pages within
those services.
Now that you have an understanding of how the user interface is structured, it's time to get started using it. As
you can see, there are a lot of features and functionality.
If all you need is a code repository and bug tracking solution, then start with Get started with Git and Manage
bugs.
To start planning and tracking work, see About Agile tools.
Connect to the web portal, user accounts, and licensing

You connect to the web portal through a supported web browser —such as the latest versions of Edge, Chrome,
Safari, or Firefox. Only users who have been added to a project can connect. This is typically done by the
organization owner.
Five account users are free as are Visual Studio subscribers and stakeholders. After that, you need to pay for
more users. Find out more about licensing from Azure DevOps pricing.
Stakeholder.
You connect to the web portal through a supported web browser—such as the latest versions of Edge, Chrome,
Safari, or Firefox. Only users who have been added to a project can connect. This is typically done by a member
of the Project Administrators group.
Stakeholder. Most regular contributors must have a TFS client access license (CAL). All Visual Studio
subscriptions include a TFS CAL. Find out more about licensing from TFS pricing.
Refresh the web portal

If data doesn't appear as expected, the first thing to try is to refresh your web browser. Refreshing your client
updates the local cache with changes that were made in another client or the server. To refresh the page or
object you're currently viewing, refresh the page or choose the Refresh icon if available.
To avoid potential errors, you should refresh your client application under the following circumstances:
Process changes are made
Work item type definitions are added, removed, renamed, or updated
Area or iteration paths are added, removed, renamed, or updated
Users are added to or removed from security groups or permissions are updated
A team member adds a new shared query or changes the name of a shared query
A build definition is added or deleted
A team or project is added or deleted
Differences between the web portal and Visual Studio

Although you can access source code, work items, and builds from both clients, some task specific tools are only
supported in the web browser or an IDE but not in both. Supported tasks differ depending on whether you
connect to a Git or TFVC repository from Team Explorer.
Web por tal

Visual Studio
Product backlog, Portfolio backlogs, Sprint backlogs, Taskboards, Capacity planning

Kanban boards
Dashboards, Widgets, Charts
Request feedback
Web-based Test Management
Administration pages to administer accounts, team projects, and teams
Git: Changes, Branches, Pull Requests, Sync, Work Items, Builds
TFVC: My Work, Pending Changes | Source Control Explorer, Work Items | Builds
Greater integration with work items and Office integration clients. You can open a work item or query result
in an office supported client.
NOTE
Visual Studio 2019 version 16.8 and later versions provide a new Git menu for managing the Git workflow with less
context switching than Team Explorer. Procedures provided in this article under the Visual Studio tab provide information
for using the Git experience as well as Team Explorer. To learn more, see Side-by-side comparison of Git and Team Explorer.
Resources
Manage projects
Project & Organizational Settings
Open a service, page, or settings
The web portal for Azure DevOps provides support for software development teams to collaborate through the
planning, development, and release cycles. You can manage source code, plan and track work, define builds, run
tests, and manage releases.
This article shows you how to navigate to functional and administrative tasks available from the web portal.
There are three levels of administrative tasks: team, project, and organization.
If you don't have a project yet, create one. If you don't have access to the project, get invited to the team.
This article shows you how to navigate to functional and administrative tasks available from the web portal.
There are four levels of administrative tasks: team, project, collection, and server.
If you don't have a project yet, create one. If you don't have access to the project, get invited to the team.
Open a service or functional task page

Services support getting work done—managing code, planning and tracking work, defining and managing
pipelines, creating and running tests, and so on.
NOTE
service on or off.
You open a service by choosing the service from the sidebar and then selecting from the available pages.
For example, here we select Boards>Backlogs .
Within the page you may select a specific view or artifact, such as a team backlog or choose another page.
You open a service by choosing it from the horizontal blue bar. Then, select from the available pages.
For example, here we select Work>Work Items .
Open team settings

Select configurations are made to teams through the team settings pages. For an overview of all team settings,
see About user, team, project, and organization-level settings.
1. Choose Project Settings .
2. Expand Boards and choose Team configuration .
3. Choose one of the pages General , Iterations , Areas , or Templates to configure settings for the team.
To learn more, see Manage teams.
4. If you need to switch to a different team, use the team selector within the breadcrumbs.
5. To add a team administrator, add team members, or change the team profile, choose Teams from the
vertical sidebar, and then choose the name of the team you want to configure.
You open team settings from the top navigation bar. Select the team you want and then choose the gear icon.
To learn more about switching your team focus, see Switch project, repository, team.
1. Choose one of the pages General , Iterations , Areas , or Templates to configure settings for the team.
To learn more, see Manage teams.
2. To add a team administrator, add team members, or change the team profile, choose Over view .
3.
Open project settings

Administrators configure resources for a project and manage project-level permissions from the Project
settings pages. Tasks performed in this context can impact the project and team functions. For an overview of
all project settings, see Project administrator role and managing projects.
1. Choose Project Settings .
2. From there, you can choose a page from the list. Settings are organized based on the service they
support. Expand or collapse the major sections such as Boards , Build and release , Code , Test , and
Extensions to select from the list.
From a user context, open Project settings by choosing the gear icon.
Open any admin page by choosing it's name. Choose or hover over the gear icon to access other
administrative options. Note that you can choose any of the user-context areas—Dashboards , Code , Work —
to return to the user context.
Open Organization settings
Organization owners and members of the Project Collection Administrators group configure resources for all
projects or the entire organization, including adding users, from the Organization settings pages. This includes
managing permissions at the organization-level. For an overview of all organization settings, see Project
collection administrator role and managing collections of projects.
Open Collection settings

Members of the Project Collection Administrators group configure resources for all projects or the entire project
collection from the Collection settings pages. This includes managing permissions at the collection-level. For an
overview of all collection-level settings, see Project collection administrator role and managing collections of
projects.
1. Choose the Azure DevOps logo to open Projects . Then choose Admin settings .
2. From there, you can choose a page from the list of settings. Settings are organized based on the service
they support. Expand or collapse the major sections such as Boards and Build and release to select a
page from the list.
1. Choose the gear icon to open Organization settings or Collection settings .
2. From there, you can choose a page. Settings are organized based on the service they support.
Open Server settings

Members of the Team Foundation Server Administrators group configure resources for the server instance from
the Server settings pages.
1. From the web portal home page for a project, choose or hover over the gear icon and select Ser ver
settings .
2. Choose Access levels , to set access levels for a member or group. For details, see Change access levels.
If you don't see Access levels , you aren't a TFS administrator and don't have permission. Here's how to
get permissions.
Related articles
Manage projects
About team, project, and admin settings
Add an artifact or team artifacts
Select the service of interest to get started adding new artifacts or objects. For example, to add work items,
choose Boards or Work . Some artifacts—such as a product backlog, Kanban board, portfolio backlogs—are
added when you add a team.
Prior to adding an artifact, make sure that you've selected the project and repository that you want to work in.
Add work items, queries, or other work tracking artifacts

You can quickly add a query or work item when working from a Boards or Work page.
Choose a Boards page—such as Work Items , Boards , or Backlogs . Then choose the plus icon and select
from the menu of options.
From a Work page, you can add a work item from the menu of options as shown in the following image.
Or, you can open one of the pages—Boards , Backlogs , Queries , or Plans —to add an artifact specific to each
of these functional pages.
To add other work tracking artifacts, see one of the following articles:
To add a board, backlog, or sprint backlog, first add a team which will be associated with those artifacts
Add a delivery plan
Add a managed work item query
Add work items.
Add a pull request or Git repository

You can quickly add a pull request, Git repository, or work item using the Add menu when working from Code .
Expand the Repos service and choose Files , Commits , or Pull Requests (Git repos) or Files , Changesets , or
Shelvesets (TFVC). Then, choose the plus icon and select from the menu of options.
For details on adding a Git repository, see Git repository.

From Code , open the context menu for the current repository and choose New repositor y . For details on
adding a Git repository, see Git repository
From one of the other Code pages, you can add files or folders, a new branch, or a new pull request.
Note that you can only add one TFVC repository per project, but an unlimited number of Git repositories. To
learn more about Git artifacts, see one of the following articles:
Git repository
Git branch
Git pull request
Add work items
Add build and release pipelines

Expand Pipelines and choose Builds or Releases . Then choose the plus icon and select from the menu of
options.
From Build and Release , choose Builds , Releases , or other page to add an artifact associated with that page.
To learn more about adding other pipeline related artifacts, see the following articles:
Deployment groups
Task groups
Variable groups
Secure files
Add a team
Agile tools and dashboards are typically associated with teams. You add teams to a project. To learn more about
teams, see About teams and Agile tools. To add a team, see Add a team and team members.
View teams already defined

To view the set of defined teams, open Project settings , and choose Over view .
To view the set of defined teams, open the admin context for the project, and choose Over view .
Add a dashboard
Dashboards are associated with a team or a project. Each team can create and configure a number of
dashboards. And, any team member can create one or more project dashboards. To learn how, see Add a
dashboard.
Dashboards are associated with a team. Each team can create and configure a number of dashboards. To learn
how, see Add a dashboard.
Add a wiki
If you don't have a wiki yet, you can add one. Once added, you can add and update pages to that wiki.
Create a wiki
Create a wiki
Related articles
Azure Artifacts
Exploratory & Manual Testing
Use breadcrumbs, selectors, and directories to
navigate and open artifacts
To quickly navigate to a feature or artifact—such as a dashboard, repository, product backlog, Kanban board,
build pipeline—you can use breadcrumbs, selectors, and directories.
Organization and project breadcrumbs

To navigate to the project summary page, choose the project link within the breadcrumbs. To navigate to the
organization page with all projects defined for the organization, choose the organization link.
Horizontal navigation doesn't provide a breadcrumb structure for the organization and project levels. Instead,
you can select a recent team or project from the project/team selector.
Choosing Browse all opens the projects page.

Selectors
Selectors are used to select an artifact within the current page. Most Agile tools are defined for a team and
therefore require selection of the team artifact or tool.
Selectors are used to select an artifact within the current page. Most Agile tools are defined for a team and
therefore require selection of the team as well as the specific page.
NOTE
When you navigate to a specific page or artifact, the system remembers your selection. You use selectors to choose a
different artifact within the current page.
Example: Dashboard selector

Within Dashboards , you open a specific dashboard from the selector.
This particular selector features these navigational elements:

Search box for filtering dashboards based on a team name or keyword
Two pages you can choose from:
Mine (dashboards you created) which are organized by team
All (dashboards created by everyone) which are listed alphabetically
Dashboards you've favorited will appear at the top of the selector
Add new dashboard feature
Browse all dashboards - opens Dashboards>All
Within Dashboards , you select the team whose dashboards you want to view.
Then, choose the name of the dashboard to view it.
For example, here we open the Work in Progress dashboard.
Example: Backlogs
From the Boards>Backlogs page, you use the selector to switch to another team's backlog. Again, favorited
backlogs appear towards the top of the menu. You can also filter the list based on a team name or keyword.
Or, choose Browse all team backlogs to open the Backlogs>All page.
(1) Select the team from the project/team selector, choose (2) Work , (3) Backlogs , and then (4) the product
backlog, which is Backlog items (for Scrum), Stories (for Agile), or Requirements (for CMMI).
To choose another team, open the project/team selector and select a different team or choose the Browse
option.
Artifact breadcrumbs and selectors

Within select pages, breadcrumbs are provided to support navigating within the page or opening an artifact.
Example: Queries folders and breadcrumbs
For example, when working in the Queries pages, you can navigate to a subfolder, folder, or page.
Also, you can choose a query that you've favorited from the selector menu, Or, you can choose to browse all
queries which returns you to the All Queries page.
Example: Pipeline folders and breadcrumbs
Breadcrumb-and-selector navigation elements are used within most services that support defining and
organizing artifacts within folders. This includes Pipelines or Build and Release applications pages.
Choose the Deployment breadcrumb link to return to the Deployment folder.
Directories
Directories provide a filterable list of all artifacts defined for a service area. Often when you navigate to an
application, it will open the application's directory.
For example, here is the Boards>Boards directory.
It lists boards in the following order:
Your last visited board
Your favorited boards
All boards of teams that you belong to
All boards defined for the project in alphabetical order.
Choose the filter icon to filter the list as described in Filter basics.
From a specific page, you can open the directory from the breadcrumbs or a selector. For example, choose
Browse all boards from the Boards selector.
Open from breadcrumb
Open from selector
Team profiles
Open a team profile to quickly access items defined for a team. The team profile is available from the
Over view>Dashboards , Boards>Boards , Boards>Backlogs , and Boards>Sprints pages.
A panel opens that shows all items defined for the team.
You can filter the list to show only Dashboards , Boards , Backlogs , or Sprints by choosing from the
menu.
To view the team admins and members of the team, choose Members .
To view or change the team configuration, choose Team Settings .

You can then add team members, team admins, or navigate to team notifications, or team iterations and
area paths.
See also Manage and configure team tools.
Related articles
About teams and Agile tools
Add an artifact or team
Set favorites
Open a service or page
Filter basics
Switch project, repository, team
Several features depend on the project, repository, or team that you have selected. For example, dashboards,
backlogs, and board views will change depending on the project and team you select.
Also, when you add a work item, the system references the default area and iteration paths defined for the team
context. Work items you add from the team dashboard (new work item widget) and queries page are assigned
the team default iteration. Work items you add from a team backlog or board, are assigned the team default
backlog iteration. To learn more, see About teams and Agile tools.
Prerequisites
You must be added to a project as a member of the Contributors or administrator security group. To get
added, Add users to a project or team.
NOTE
If the Limit user visibility and collaboration to specific projects preview feature is enabled for the organization,
users added to the Project-Scoped Users group won't be able to access projects that they haven't been added to. To
learn more, see Manage your organization, Limit user visibility for projects and more.
View and open a project

From the Projects page you can quickly navigate to a project that you have permissions to view.
1. Choose the Azure DevOps logo to open Projects .
The projects you most recently viewed are displayed, followed by a list of all projects in alphabetic order.
2. Hover over the dots and you can open the service of interest for that project.
3. You can filter the project and team list using the Filter projects search box. Simply type a keyword
contained within the name of a project or team. Here we type Fabrikam to find all projects or teams with
Fabrikam in their name.
4. Choose Create Project to add a project. You must be an account administrator or a member of the
Project Collection Administrators group to add a project.
From the Projects page you can quickly navigate to a project or a team that you've accessed or worked in
previously. Projects and teams are listed in the order you've last accessed, with the most recent five projects
accessed appearing first. All projects you've accessed are listed within the All section.
1. Choose the Azure DevOps logo to open Projects .
The projects you most recently viewed are displayed, followed by a list of all projects in alphabetic order.
2. As you hover over a project or team, you can choose one of the links to go to Home or Dashboards ,
Code , Work , Build and Release , Test , or Wiki pages. Choose the star icon to mark the project as a
favorite.
3. You can filter the project and team list using the Filter projects and teams search box. Simply type a
keyword contained within the name of a project or team. Here we type Fabrikam to find all projects or
teams with Fabrikam in their name.
4. Choose New Project to add a project. You must be an account administrator or a member of the Project
Collection Administrators group to add a project.
View and open a repository

1. Choose Repos>Files .
2. Select the repository of interest from the repository selector.

1. Choose Code .
2. Select the repository from the selector.

Switch to a different team
From a user page, one under—Boards , Repos , Pipelines , or Test Plans —you can't switch to a different team,
you can only select team artifacts.
From a Project Settings>Work>Team configuration page, you select a team from the team selector
breadcrumb.
You can switch your team focus to one that you've recently viewed from the project/team selector. If you don't
see the team or project you want, choose Browse… or choose the Azure DevOps logo to access the
Projects page.
Related articles
Work across projects
Add teams
Tutorial: Set personal or team favorites
Favorite those views that you frequently access. You can favorite all sorts of Azure DevOps features and tools
—such as a project, repository, build pipeline, dashboard, backlog, board, or query. You can set favorites for
yourself or your team.
As your code base, work tracking efforts, developer operations, and organization grows, you'll want to be able to
quickly navigate to those view of interest to you and your team. Setting favorites allows you to do just that.
Team favorites are a quick way for members of your team to quickly access shared resources of interest. You
favorite an item for yourself by choosing the star icon. The favorited item will then show up easily from one
or more directory lists. You set favorites for a team through the context menu for the definition, view, or artifact.
In this tutorial you'll learn how to view your personal favorites and to favorite or unfavorite the following views:
Project or team
Dashboard
Team backlog, board, shared query, or other Azure Boards view
Repository
Build and release definition
Test plans
Project
Shared query
Repository
Build and release definition
Test plans
Prerequisites
You must connect to a project through the web portal. If you don't have a project yet, create one. To connect
to the web portal, see Connect to a project.
You must be a member of the Contributors or an administrators security group of the project. To get added,
Add users to a project or team.
To favorite projects, backlogs, boards, queries, dashboards, or pipeline views, you must have Stakeholder
access or higher.
To favorite repositories, or delivery plans, you must have Basic access or higher.
To favorite test plans, you must have Basic + Test Plans access level or equivalent.
You must connect to a project through the web portal. If you don't have a project yet, create one. To connect
to the web portal, see Connect to a project.
You must be a member of the Contributors or an administrators security group of the project. To get added,
Add users to a project or team.
To favorite projects, backlogs, boards, queries, dashboards, or pipeline views, you must have Stakeholder
access or higher.
To favorite repositories, or delivery plans, you must have Basic access or higher.
To favorite test plans, you must have Basic + Test Plans access level or equivalent.
For details about the different access levels, see About access levels.
View personal favorites

Access views that you have favorited by choosing the inbox icon, and then choosing Favorites .
NOTE
If a service is disabled, then you can't favorite an artifact or view of that service. For example, if Boards is disabled, then
the favorite groups—Plans, Boards, Backlogs, Analytics views, Sprints, and Queries and all Analytics widgets—are disabled.
To re-enable a service, see Turn an Azure DevOps service on or off.
1. Access views that you have favorited by choosing the Azure DevOps logo to open Projects .
2. Choose My Favorites to quickly access any view or item that you've marked as a favorite.
Favorite a project or team
1. To favorite a project, open the project Summar y page and choose the star icon.
2. To favorite a team artifact, open Boards>Boards or Boards>Backlogs . Select the team you want to
favorite from the team selector and choose the star icon.
3. To favorite other team artifacts, choose the team icon, and then choose the star icon next to one of
the listed artifacts.
Favorite a project
To favorite a project, open the project Summar y page and choose the star icon.
Or, you can favorite a project from the Projects page by choosing the star icon next to the project.
Favorite a dashboard
1. From Over view>Dashboards , open the selector and choose the Browse all dashboards option.
2. The Mine page shows your favorited dashboards, and all dashboards of teams that you belong to. The
All page (shown below) lists all dashboards defined for the project in alphabetical order. You can filter the
list by team or by keyword.
TIP
You can change the sort order of the list by choosing the column label.
3. To favorite a dashboard, hover over the dashboard and choose the star icon.
Favoriting a dashboard will cause it to appear on your Favorites page and towards the top in the
Dashboards selection menu.
Favorite a team's backlog, Kanban board, or other view

You can favorite several Agile tools for a team from a Boards page.
1. Choose Boards , and then choose the page of interest, such as Boards , Backlogs , or Sprints .
For example, here we choose (1) Work and then (2) Backlogs .
To choose a specific team backlog, open the selector and select a different team or choose the Browse
all team backlogs option. Or, you can enter a keyword in the search box to filter the list of team
backlogs for the project.
2. Choose the star icon to favorite a team backlog. Favorited artifacts ( favorited icon) appear on your
Favorites page and towards the top of the team backlog selector menu.
Favorite a shared query

Open Boards>Queries and choose the All page. Expand a folder as needed. Choose the star icon next to
the query you want to favorite.
Or, open the context menu of the query, and then select Add to Team Favorites , and then select from the list of
teams.
NOTE
You must be a member of at least one team for the Add to Team Favorites option to be visible. If not visible, ask your
project administrator or team administrator to add you to a team.
You can also set a query as a personal favorite by opening the query and choosing the star icon.
Open Work>Queries . Next, open the actions icon menu of the shared query you want to favorite, and then
select Add to my favorites or Add to team favorites .
Favorite a delivery plan

To learn more about delivery plans, see Review team Delivery Plans.
To mark a delivery plan as a favorite, open the Boards>Plans page and choose the star icon next to the
Delivery Plan.
To mark a delivery plan as a favorite, open the Work>Plans page and choose the star icon next to the
Delivery Plan.
Favorite a repository
From any Repos page, open the repository selector and choose the star icon for the repository you want to
favorite.
From any Code page, open the repository selector and choose the star icon next to the repository you want
to favorite.
Favorite a build pipeline

Open Pipelines>Builds and choose either Mine or Definitions page. Choose the star icon next to the
build definition you want to favorite. Or, open the context menu of the build definition, and then select Add to
my favorites or Add to team favorites .
Open Build and Release>Builds and choose either Mine or Definitions page. Choose the star icon next
to the build definition you want to favorite. Or, open the context menu of the build definition, and then select
Add to my favorites or Add to team favorites .
Favorite a test plan
To learn more about test plans, see Create a test plan and test suite.
To mark a test plan as a favorite, open Test Plans>Test Plans and choose the star icon next to a test plan
from the menu that shows All test plans.
To mark a test plan as a favorite, open the Test>Test Plans page and choose the star icon next to a test plan
from the menu that shows All test plans.
Unfavorite a view you've favorited

You can unfavorite an artifact from your Favorites page. Choose the inbox icon, and then choose Favorites .
Choose the favorited icon of a currently favorited artifact.
Similarly, you can unfavorite an artifact from the same page where you favorited it.
You can unfavorite an artifact from the Projects>Favorites page and choose the favorited icon of a
currently favorited artifact.
Similarly, you can unfavorite an artifact from the same page where you favorited it.
Try this next

Follow a user story, bug, issue, or other work item or pull request
Related articles
Set your preferences
Filter lists, boards, and directories
Several applications and pages support filtering, which is very useful when a large number of artifacts or items
have been defined. Most directory views provide one or more filter functions.
You can filter most items using keywords or a user name for an author of an item or where work is assigned to
them. You can filter lists and boards in the following areas:
Git repositories: Branches, Commits, Commit history, Pull Requests, Pushes, and Repositories
Work tracking: Work Items, Kanban boards, Backlogs, Sprint Backlogs, and Taskboards
Directories: Dashboards, Boards, Backlogs, Sprints, Queries, Builds, Releases
Git repositories: Branches, Commits, Commit history, Pull Requests, Pushes, and Repositories
Work tracking: Work Items, Kanban boards, Backlogs, Sprint Backlogs, and Taskboards
NOTE
You may have fewer or additional filter options based on the features you've enabled or the platform and version that you
are working from.
Filter based on keywords, tags, or fields

To turn filtering on, choose the filter icon.
You can filter work items by typing a keyword or using one or more of the fields provided, such as work item
type, assigned to, state, and tags. Based on the keyword that you enter, the filter function will list work items
based on any visible/displayed column or field, including tags. Also, you can enter a value for an ID, whether or
not the ID field is visible.
The filtered set is always a flat list, even if you've selected to show parents.
Characters ignored by keyword filter criteria
The filter criteria ignores the following characters: , (comma), . (period), / (forward slash), and \ (back
slash).
Filter directories
Choose the filter icon to filter a directory list by keyword, team, or other supported field. Keywords apply to
titles, descriptions, and team names.
For example, here we turn filtering on for the dashboard directory.
Related articles
Commit history
Working with Git tags
Filter backlogs and queries
Filter your Kanban board
Add tags to work items
Keyboard shortcuts for Azure DevOps and Team
Explorer
You can use the keyboard shortcuts listed in this article when you work within Azure DevOps or Team Explorer.
In addition to these shortcuts, you can assign your own shortcuts in Visual Studio from the
Tools/Options/Environment/Keyboard page.
For specific guidance on navigating within the web portal, see Web portal navigation.
Web portal
You can use these keyboard shortcuts when working in the web portal for Azure DevOps.
Navigate within lists
SH O RTC UT A C T IO N
Tab Move focus
←→ Move focus left/right
↑↓ Move focus up/down
Ctrl+Home Move focus to top of list
Ctrl+End Move focus to bottom of list
Ctrl+↑↓ Move item up/down within list
Shift+↑↓ Highlight consecutive items
Menu Open context menu
Esc Dismiss context menu
Enter Choose selected menu item
Web portal, global shortcuts

Type ? to access the Global and page-specific shortcuts.
You can use the following keyboard shortcuts from the web portal.
? Show keyboard shortcuts
p Go to Projects and teams
g,h Go to Projects home

g,b Go to Pipelines
g,c Go to Repos
g,t Go to Test Plans
g,s Go to Project Settings
g,w Go to Boards
/ or s Move focus to search

f,n Focus next section
f,p Focus previous section
You can use the following keyboard shortcuts from the web portal.
? Show keyboard shortcuts
p Go to Projects and teams
g,h Go to Projects home

g,w Go to Boards or Work
g,c Go to Repos or Code
g,b Go to Pipelines or Build and release
g,t Go to Test Plans or Test
g,s Go to Project Settings
f,n Focus next section

f,p Focus previous section
/ Move focus to search
Page-specific shortcuts only work when in a specific page. For example, type g c to open the Code page, and
then type c p to create a pull request. These navigation shortcuts work as long as the focus is not on an input
control.
Repos
Code
You can use the following keyboard shortcuts when working from a page under Repos . To view the valid
shortcuts, enter ? to access Global and service-specific shortcuts.
You can use the following keyboard shortcuts when working from a page under Code . To view the valid
shortcuts, enter ? to access Global and service-specific shortcuts.
Git repositories
Repos-Git
z Toggle full-screen mode

e Open explorer
h Open history
b Open branches
q Open pull requests
c,p Create pull request
r Select repository
Files
1 Open contents
2 Open history
t Move focus to directory path
w Select branch
TFVC repositories
Repos-TFVC
r Select repository
Code
e Open Files
c Open changesets
v Open shelveshets
Files
1 Open contents
2 Open history
Code
r Select repository
e Open explorer
h Open history
b Open branches (Git)
q Open pull requests (Git)
c,p Create pull request (Git)
File Explorer
1 Open contents
2 Open history
w Select branch (Git)
y Switch to commit (Git)
c,b Create branch (Git)
Work Items
You can use the following keyboard shortcuts when working from the Boards>Work Items or Work>Work
Items page.
NOTE
The following shortcuts are available from the web portal for Azure DevOps Server 2019 and later versions.
w Open work items
l Open backlog
b Open board
i Open sprint
q Open queries
z Toggle full screen
Ctrl+Shift+f Filter results

Ctrl+c Copy to clipboard
Delete Delete
l Open backlog
b Open board
i Open current iteration
t Open task board
q Open queries
z Toggle full screen

Ctrl+c Copy to clipboard
Delete Delete
Work item form shortcuts

You can use the following keyboard shortcuts when interacting with a work item form. To view the valid
shortcuts, enter ? from within the form.
NOTE
The following shortcuts are available from the web portal for Azure DevOps Server 2019 and later versions.
Alt+i Assign work item to me

Ctrl+Shift+d Go to discussion
Ctrl+s Save changes
Shift+Alt+c Copy work item title
Ctrl+Shift+, Move to left tab (page)
Ctrl+Shift+. Move to right tab (page)
Alt+i Assign work item to me
Ctrl+Shift+d Go to discussion
Ctrl+s Save changes
Shift+Alt+c Copy work item title
Ctrl+Shift+, Move to left tab (page)
Ctrl+Shift+. Move to right tab (page)
Rich text field shortcuts

The rich text editor tool bar displays below the text entry area when you click your cursor within the each text
box that can be formatted.
You can use the following keyboard shortcuts when working in a web browser on one of the following
operating systems. (Command = )
W IN DO W S O S SH O RTC UT S M A C O S SH O RTC UT S
Ctrl + b = Bold Command + b = Bold

Ctrl + c = Copy text Command + c = Copy text
Ctrl + i = Italics Command + i = Italics
Ctrl + k = Insert hyperlink Command + k = Insert hyperlink
Ctrl + s = Save Command + s = Save
Ctrl + u = Underline Command + u = Underline
Ctrl + v = Paste text Command + v = Paste text
Ctrl + y = Redo Command + Z = Redo
Ctrl + z = Undo Command + z = Undo
Ctrl + . = Bullet list Command + . = Bullet list
Ctrl + / = Numbered list Command + / = Numbered list
Shift + : = Emoji library Shift + : = Emoji library
The rich text formatting toolbar appears above each text box that can be formatted. It only becomes active when
you click within the text box.
You can use the following keyboard shortcuts when working in the editor from a web browser running on a
Windows operating system.
Ctrl + b = Bold
Ctrl + c = Copy text
Ctrl + i = Italics
Ctrl + k = Insert hyperlink
Ctrl + s = Save
Ctrl + u = Underline
Ctrl + v = Paste text
Ctrl + y = Redo
Ctrl + z = Undo
Ctrl + . = Bullet list
Ctrl + / = Numbered list
CTRL+Spacebar = Remove formatting
Boards
You can use the following keyboard shortcuts from any Kanban board, that is, when working from
Boards>Boards or Work>Board page.
n Add new item

c Add new child item
Home Select first item

Enter Open item
Ctrl+↑ Move item up

Ctrl+↓ Move item down
Ctrl+← Move item left
Ctrl+→ Move item right
Ctrl+Home Move item to top of column

Ctrl+End Move item to bottom of column
Ctrl+Shift+↑ Move item to swimlane above
Ctrl+Shift+↓ Move item to swimlane below
F2 Rename item
e Show/hide empty fields
o Expand all swimlanes
u Collapse all swimlanes
Shift+Pageup Select first/next swimlane above

Shift+Pagedown Select last/next swimlane below
n Add new item
c Add new child item

Enter Open item

Ctrl+Home Move item to top of column

Ctrl+End Move item to bottom of column
Ctrl+Shift+↑ Move item to swimlane above
Ctrl+Shift+↓ Move item to swimlane below
F2 Rename item
e Show/hide empty fields
o Expand all swimlanes
u Collapse all swimlanes
Shift+Pageup Select first/next swimlane above

Shift+Pagedown Select last/next swimlane below
Backlogs
You can use the following keyboard shortcuts when working from a Boards>Backlogs page. These shortcuts
work when you are on a product backlog, portfolio backlog, or sprint backlog page.
m,b Move item to backlog

m,i Move item to current iteration
m,n Move item to next iteration
Ins Add child
f+i Add child
Ctrl+Home Move item to top

Ins Add child
Ctrl+Shift+f Filter resultsBacklogs page. These shortcuts
work when you are on a product backlog, portfolio backlog, or sprint backlog page.
Backlogs
Ctrl+Home Move item to top

n Open new item panel

Ins Add child
r Show/Hide Parents
Queries
You can use the following keyboard shortcuts when working with queries in the web portal. To view the valid
shortcuts, enter ? from Boards>Queries or Work>Queries .
c q New query
r or Alt+r Refresh query
Alt+q Return to query
j or Alt+n Next item
k or Alt+p Previous item
c q Add new query

r or Alt+r Refresh query
Alt+q Return to query
j or Alt+n Select next item
k or Alt+p Select previous item
Plans
To toggle between card titles only and card details, enter t .
NOTE
Type ? to access Global and service-specific shortcuts.
Enter Open item
n New item

Shift+← Pan timeline left
Shift+→ Pan timeline right
u Collapse all backlogs

o Expand all backlogs
Shift+pageup Focus on previous team

Shift+pagedown Focus on next team
Test Plans, Parameters, and Runs

You can use the following keyboard shortcuts when working in Test Plans or Test .
NOTE
The following shortcuts are available from the web portal for Azure DevOps Services and TFS 2015.2 or later versions.
Test
n Open test plans

m Open shared parameters
r Open runs
h Open machines
Test plan
1 Open tests
2 Open charts
e Execute tests
t,b Mark selected tests as blocked

t,f Fail selected tests
t,n Mark selected tests as NA
t,p Pass selected tests
t,r Reset tests to active

v,g View grid
Parameters
1 View parameter set grid

2 Open properties
c,s Add parameter set

c,t Add test case
v,t Toggle test cases pane
Test runs
1 Test runs
2 Filter
Wiki
NOTE
Keyboard shortcuts to manage Wiki pages are supported on TFS 2018.2 or later versions. To download TFS 2018.2, see
Team Foundation Server 2018 Update 2 Release Notes.
You can use the following keyboard shortcuts when managing or editing Wiki pages. To view the valid shortcuts,
enter ? from a Wiki page.
NOTE
The following shortcuts are available from the web portal for TFS 2018.2 and later versions.
n Add new page

e Edit page
c Create new sub-page
Ctrl+P Print page
Ctrl+Shift+b Create work item from selected text
Ctrl+b Bold text

Ctrl+c Copy text
Ctrl+s Save changes

Esc Close
n Add new page
e Edit page
c Add new sub-page
Ctrl+P Print page
Ctrl+Shift+f Filter page
Ctrl+b Bold text

Ctrl+c Copy text
Ctrl+s Save changes
Esc Close
Team Explorer navigational shortcuts

Use these shortcuts when working in Team Explorer.
Navigate
Ctrl+0,a Open web portal
Ctrl+0,b Open Build
Ctrl+0,c Open Connect
Ctrl+0,d Open Documents
Ctrl+0,e Open Branches (Git)
Ctrl+0,g Open Changes (Git)
Ctrl+0,h Open Home
Ctrl+0,m Open My Work (TFVC)
Ctrl+0,p Open Pending changes (TFVC)
Ctrl+0,r Open Reports
Ctrl+0,s Open Settings
Ctrl+0,w Open Work items
Ctrl+0,y Open Synchronization (Git)
Ctrl+' Move focus to search box
Alt+0 Move focus to top of page
Alt+1 …9 Move focus to visible section [1 thru 9]
Alt+↑↓ Move focus to next/previous section
Context menu
↓ Open a context menu<
Esc Dismiss a context menu
←→ Move focus left/right
↑↓ Move focus up/down
Enter Choose Context menu
Work item commands
Alt+m,g Open work item
Alt+m,i Add a work item
Alt+m,q Add a query
Shift+Alt,c Copy selected work item
Shift+Alt,l Link to new work item
Enter Open selected work item
You can use query results shortcuts whenever you have a list of work items, such as the query results view or a
list of linked work items within a work item form.
Q UERY EDITO R A C T IO N Q UERY RESULT S A C T IO N
←→ Move focus left/right ←→ Scroll left/right
↑↓ Move focus up/down PgUp/PgDn Scroll up/down
Shift+↑↓ Highlight consecutive Shift+↑↓ Highlight consecutive rows

clauses
Shift+← Move focus left one field at Shift+Alt,n Move focus to next item
a time
Shift+→ Move focus right one field Shift+Alt,p Move focus to previous
at a time item
End Move focus to end of End Move focus to bottom of

current clause list
Q UERY EDITO R A C T IO N Q UERY RESULT S A C T IO N
Enter Move focus down Enter Open selected work item
Tab Move focus right, one field Home Move focus to top of list
at a time
Ctrl+c Copy selected clause +/- Expand/collapse current row
Ctrl+s Save changes (editor) Ctrl+s Save changes (results)
Ctrl+v Paste copied clause F5 Refresh
Del Delete contents of current

field or clause
Related articles
Keyboard shortcuts for Microsoft Test Manager
Identify and customize keyboard shortcuts in Visual Studio
Default keyboard shortcuts for Visual Studio
Accessibility Features of Visual Studio
Install Team Explorer
Team Explorer is a plug-in to Visual Studio. By installing the free Visual Studio Community, other Visual Studio
version, or Visual Studio Team Explorer 2017 you gain access to Team Explorer.
Learn more about working in Team Explorer.
Manage or enable features
As new features are introduced, you can turn them on or off. That way, you can try them out, provide feedback,
and work with those features that meet your requirements.
Some preview features provide access to entire new functionality. Others, such as the New Wiki experience,
reflect a change to the user interface, but little or no change in functionality.
NOTE
It may take up to three weeks after a release to Azure DevOps Services for the preview feature to appear in your
organization. The latest release notes usually provide information on new preview features. You can turn on or off select
features for Azure DevOps Services. Preview features become available first on Azure DevOps Services and then become
standard features with an update to Azure DevOps Server. At some point, the preview feature moves out of preview
status and becomes a regular feature of the web portal.
There are a few features you or an administrator can enable or disable. Some features provide access to entire
new functionality, while others provide a change to the user interface.
The follow table indicates which preview features can be enabled per user or team member, and those that can
be enabled for the organization. You must be a member of the Project Collection Administrators group to
change a preview feature at the organization-level.
P REVIEW F EAT URES P ER USER P ER O RGA N IZ AT IO N
Analytics Views ️
✔ ️
✔
Copy Dashboard Experience ️

✔ ️
✔
Dependency Tracker Preview Features ️

✔ ️
✔
(ignore this setting)
Experimental themes ️
✔ ️
✔
Full Access to Azure Pipelines for ️

✔
Stakeholders
Limit user visibility and collaboration ️

✔
to specific projects
New account manager ️

✔ ️
✔
New Artifacts (Feeds) Experience ️

✔ ️
✔
(accessibility updates)
New Boards Hubs ️

✔ ️
✔
New boards reports ️

✔ ️
✔
P REVIEW F EAT URES P ER USER P ER O RGA N IZ AT IO N
New release progress views ️

✔ ️
✔
New service connections experience ️

✔ ️
✔
New Settings Search in the ️

✔ ️
✔
organization settings panel
New Teams page ️

✔ ️
✔
New Wiki experience ️

✔ ️
✔
Organization Permissions Settings ️

✔ ️
✔
Page v2
Project Permissions Settings page ️

✔ ️
✔
Task Insights for Failed Pipeline Runs ️

✔ ️
✔
YAML templates editor ️

✔ ️
✔
The following table indicates those features that you can enable as a user, project administrator, or project
collection administrator. These preview features are only available to manage for Azure DevOps Server 2020
RTW.
F EAT URE USER P RO JEC T C O L L EC T IO N
New service connections ️

✔ ️
✔
experience
Selective artifacts download ️

✔ ️
✔
feature for collection/project
Enable features for your use

From time to time, a new feature is introduced in Preview mode, which allows you to turn it on or off.
To access the Preview features options, open your profile menu. The profile menu appears as shown below
based on whether the New Account Manager feature has been enabled or not. The New Account Manager
preview feature turns on enhanced user interface options for managing account information. The menu options
move under the User settings icon from where they were previously under the Account manager for your
account icon.
New Account Manager enabled
New Account Manager not enabled
Choose User settings , and then choose Preview features .

To enable or disable a feature, choose the slider.
For information on other user settings and preferences, see Set user preferences.
Enable features at the organization level

When you enable a feature at the organization level, you essentially turn it on for all users of your account. Each
user can then disable the feature if they so choose. If you disable a feature at the organization level, user settings
are not changed. Users can enable or disable the feature on their own.
TIP
If you don't see the for this account menu option, then you aren't a member of the Project Collection Administrators
group. To get added as one, see Change project collection-level permissions.
Enable or disable a feature
1. Open your profile menu by choosing your image icon and select Manage features .
2. Select the level from the menu provided.
TIP
If you don't see the for this project or for this collection menu options, then you aren't an administrator. To
get added as one, see Change project collection-level permissions.
3. To enable or disable a feature, choose the slider.

User-level
Project-level
Collection-level
When you enable a feature at the project or collection-level, you essentially turn it on for all users. If you disable
a feature at the project or collection-level, user settings are not changed. Users can enable or disable the feature
on their own.
Experimental themes
When you select Theme from the Profile menu you can select between Dark and Light themes for the display
of Azure DevOps web portal.
With Experimental themes enabled, you can select among a number of additional themes.
Features now enabled for all Azure DevOps Services
General
New user hub
New PAT experience
New Navigation
Wiki
Combine email recipients
New experience in Code, Work Item, & Wiki search
Out of the box notifications
Team expansion for notifications
Streamlined User Management
Azure Artifacts
NuGet.org upstream sources
Updated package experience
Azure Boards, Dashboards, and Analytics
New Delivery Plans Experience
Enable group by tags for work item chart widget on dashboard
New Rich Text Editor
New Queries Experience
New Work Items
New Dashboards Experience
Azure Repos
New TFVC pages
Git Forks
New Repos pull request experience
New Repos settings experience
New Repos landing pages
Pull Request Status Policy
Azure Pipelines
Historical graph for agent pools
Pipeline decorators
Multi-stage pipelines
Test tab in new web platform
Test analytics in new web platform
New builds hub
Build with multiple queues
New Releases Hub
Approval gates in releases - New Release Definition Editor
Symbol server
Task tool installers
Azure Test Plans
New Test Plans Page
New Test Plan Experience
Related articles
Azure DevOps Feature Timeline
View and update work items via the mobile browser
With the mobile browser and work item form, you gain on-the-go features to stay on top of the latest updates
made to work tracking. When you click any work item link on your mobile device, it will open a mobile-friendly
version of the work item. From there, you can update the work item or access all work items assigned to you or
that you're following.
NOTE
The mobile browser supports Azure DevOps work tracking. To sign up for free, go to Azure DevOps Services. The mobile
browser is not an app, but a mobile view into select features. There is nothing to download. You access the mobile
browser by clicking a link from a work item you receive in your mobile email application.
NOTE
The mobile browser is available for TFS 2018 and Azure DevOps Server 2019 and later versions. For downloads, see
Downloads. The mobile browser is not an app, but a mobile view into select features. There is nothing to download. You
access the mobile browser by clicking a link from a work item you receive in your mobile email application.
Open the mobile work item form

The mobile work item form will open when you click View work item from an email you receive from your
mobile device. You'll receive this type of email under these circumstances:
Changes were made to a work item you're following
You were @mentioned in a discussion
A notification is sent based on the work item alerts you've set using Manage personal notifications.
Update a work item

Within the mobile form, you can do almost everything you can do from the web portal form. Here are the
actions you can take in the order they appear in the mobile form:
Add and remove tags
View and add to the discussion, click on the comment to add to the discussion
View and update any field within the form (Assign to, State, Area, Iteration, Description, and more)
View and open a link within the Development section
View History
View and open a link from the Links tab
Open and add an attachment from the Attachments tab
Actions not available to you within the mobile work item form:
You can't create or add new work items
You can't initiate a development operation
You can't add a link
Interact with mobile form controls
Mobile form controls operate as follows:
Click any field to edit it and the form changes to a full-screen experience. For example, some of the most
common actions such as changing the state of an item, moving to a different area path, adding an
attachment, and creating/removing tags are all supported.
When done, click the return option.

Remember to click the save icon to save your changes!
Update status (change State )
To update the state, click the state you want.
Add or remove tags

To add a tag, type the text you want.
View history
Click the History tab to view history.
View and open work items in your activity lists
From within the mobile work item form, you can access your work items. The mobile browser allows you to
view and open work items which fall into these categories:
Assigned to me : lists all work items assigned to you
Following : lists all work items that you have elected to follow
My activity : lists all work items that you have recently viewed or updated.
The lists available from each page span all team projects that you work in.
To access a list, first click the list control from the work item form you've opened.
Then, click Work items .
The browser opens to the Assigned to me page. From there, you can choose Following or My activity to
access the other pages. To learn more about the Work Items view, see View and add work items.
Related articles
Additional experiences are in the works to improve and expand on the mobile experience. For more information,
see the blog post: The mobile work item form (preview).
Set personal notifications
Set team notifications
Follow a work item
Provide feedback for the mobile experience
Help us improve the mobile experience.
To provide feedback, choose the list control from the work item form and then click Send Feedback . To
complete the feedback, select either the smile or frown and optionally enter a comment.
Project management and navigation glossary
This glossary describes terms used when navigating in the web portal for Azure DevOps. See also:
Agile glossary
Security glossary
Backlogs
An interactive list of work items that corresponds to a team's project plan or roadmap for what the team plans
to deliver. The product backlog supports prioritizing work, forecasting work by sprints, and quickly linking work
to portfolio backlog items. You can define your backlog items and then manage their status using the Kanban
board.
Each product backlog can be customized by a team. Learn more: Create your backlog.
Analytics views
Analytics views provide a simplified way to specify the filter criteria for a Power BI report based on the Analytics
service. The Analytics service is the reporting platform for Azure DevOps Services.
Area path
Area paths are used to group work items by team, product, or feature area. Iteration paths are used to group
work into sprints, milestones, or other event-specific or time-related periods. You can use area paths to define a
hierarchy of paths. To learn more, see About area and iteration paths.
Boards (Kanban)
An interactive, electronic sign board that supports visualization of the flow of work from concept to completion
and lean methods. Learn more: Kanban basics.
Collections
A collection is a container for a number of projects in Azure DevOps. A default collection is created when you
sign up with Azure DevOps Services or install Team Foundation Server. Within Azure DevOps Services, a
collection corresponds to an organization. For on-premises TFS deployments, you can add and manage
collections to specify the logical and physical resources available to the projects within the collection.
Learn more: About projects and scaling your organization, Manage organizations or Manage project collections
in Team Foundation Server.
Dashboards
Dashboards are user-configurable interactive signboards that provide real-time information. Dashboards are
associated with a team and display configurable widgets to show information. To learn more, see Add and
manage dashboards.
Extensions
Extensions are simple add-ons that are used to customize and extend the DevOps experience of Azure DevOps.
They're written with standard technologies—HTML, JavaScript, CSS—and can be developed using your
preferred development tools. Hundreds of extensions are available from the Visual Studio Marketplace, Azure
DevOps tab.
Favorites
Tagging an object as a favorite is a method used to support quick navigation by yourself or other team
members. You can tag work item queries and build definitions as personal and team favorites. Other objects you
can tag as a favorite for yourself only include code branches, delivery plans, test plans, and teams or projects. To
learn more, see Set personal or team favorites.
Follow
Tagging specific work items or pull requests to follow them is a method used to receive email updates about
changes that are made to them. To learn more, see Follow a work item or pull request.
Git repository
A Git repository supports a distributed version control system for tracking changes, reviewing contributions to
the code, and more. Each developer has a copy of the source repository on their dev machine. You can add
multiple Git repositories to a project. Learn more: Git Repositories.
NOTE
Git in Visual Studio and Azure DevOps Services is standard Git. You can use Visual Studio with third-party Git services,
and you can also use third-party Git clients with Azure DevOps Services.
Notifications
With notifications, you receive an email when changes occur to work items, code reviews, pull requests, source
control files, and builds. For example, you can get notified whenever a bug that you opened is resolved, or when
a work item is assigned to you. You receive notifications based on rules or subscriptions made by you, for your
teams, or for the project. Learn more: About notifications.
Pipelines
Pipelines are artifacts that you define to run concurrent builds or deploy concurrent releases. Two types of
pipelines are supported, private and hosted. To learn more, see CI/CD concurrent jobs.
Plans (also known as delivery plans)

A plan is a configurable view that displays work from multiple teams and projects laid out within a calendar
based on each team's iterations. Each row in the view represents the work from a team's product or portfolio
backlog. Each card corresponds to a work item, such as user story, feature, or epic. To learn more, see Review
team delivery plans.
Process
A process defines the building blocks of a work-tracking system. To customize a process, you first create an
inherited process from one of the default system processes, Agile, Scrum, or CMMI. All projects that use the
process see the changes you make. To learn more, see About process customization and inherited processes.
Projects
A project, which was previously known as a team project, provides a repository for source code. A project
provides a place where a group of people can plan, track progress, and collaborate on building software
solutions. A project is defined for an Azure DevOps Services organization or within a TFS project collection. You
can use it to focus on those objects defined within the project. To learn more, see About projects and scaling
your organization.
Public projects
A project created within an Azure DevOps Services organization that is visible to the whole world. Everyone in
the world can discover them and perform limited operations. You can use the Azure DevOps CLI to discover a
list of projects. Administrators can control who gets to fully contribute. Administrators can switch a project from
private to public, and vice-versa, as described in Change the project visibility.
Queries
Queries are used to find and list work items. Queries support managed searches, which are used to triage work,
versus ad-hoc searches, which are used to find a specific work item. Flat-list queries also support status and
trend charts. To learn more, see About managed queries.
Repositories
A source control folder or container you configure to help you track file changes in. You can have any number of
repositories on your computer, each stored in their own folder. Each repository is independent, so changes saved
in one repository don't affect the contents of another. Learn more: Create a new Git repo.
Sprints (also known as iterations)

A sprint is a time period of usually two to three weeks that's used to group work items to be completed during
that time period. Sprints are used in Scrum methods to support sprint planning, sprint burndown, and other
Scrum processes. Sprints are defined via iteration paths. To learn more, see About area and iteration paths (aka
sprints).
Sprint backlog
An interactive list of work items that have been assigned to the same sprint or iteration path for a team. The
sprint backlog supports teams that use Scrum methodologies. Learn more: Sprint planning.
Taskboard
A taskboard is an interactive board of work items that you can use to review and update tasks defined for the
sprint backlog. The taskboard supports teams that use Scrum methodologies. To learn more, see Update and
monitor your taskboard.
Teams
A team corresponds to a selected set of project members. With teams, organizations can subcategorize work to
better focus on all the work they track within a project. Each team gets access to a suite of Agile tools. Teams can
use these tools to work autonomously and collaborate with other teams across the enterprise. Each team can
configure and customize each tool to meet their work requirements. To learn more, see About teams and Agile
tools.
Team Foundation Version Control (TFVC)

A centralized version control system. With TFVC, devs have only one version of each file on their dev machines.
Branches are path-based and created on the server. Historical data is maintained only on the server. Learn more:
Use Team Foundation Version Control.
Widgets
Widgets display information and charts on dashboards. Many of them can be configured. Many widgets display
information available from one or more data stores or charts created by the system. To learn more, see Widget
catalog.
Work items
A work item represents an object stored in the work item data store. Each work item is based on a work item
type—such as a user story, feature, bug, task, or issue— and is assigned an identifier which is unique across all
projects in an organization or project collection. The work item types available to you are based on the process
used when your project was created. Each work item supports capturing information, adding attachments,
linking to other work items, and more. Learn more: About work items.
Work item types (WITs)

A WIT specifies the fields, workflow, and form used to track an item of work. Each WIT is associated with more
than 30 system fields and several more type-specific fields. You use work items to plan and track the work
required to develop your project. For an overview of predefined WITs provided with the default processes, see
Choose a process.
About requesting and providing feedback
You can request feedback using one of two tools, through the Test & Feedback extension or through the Request
feedback link you access from a dashboard.
NOTE
This article is about using Azure DevOps feedback tools. To provide feedback about Azure DevOps, see Provide product
and content feedback.
About the Test & Feedback extension

Using the Test & Feedback extension is a simple, three step process:
Capture your findings quickly and easily using the tools in the extension. Capture notes, screenshots
with annotations, and screen recordings to describe your findings and highlight issues. Additionally, in
the background the extension automatically captures rich data such as user actions as an image action
log, page load data, and system information about the browser, operating system, memory, and more
that can serve as a starting point for debugging.
Create work items such as bugs, tasks, and test cases directly from the extension. The captured findings
automatically become a part of the work item. Users can file a bug to report an issue with the product, or
create a task that indicates a new work requirement. The extension can also be used to create test cases
for scenarios discovered during exploration.
Collaborate with your team by sharing your findings. Export your session report in Standalone mode,
or connect to Azure DevOps or Team Foundation Server (2015 or later) for a fully integrated experience
including exploring user stories and backlog items, simplified tracking and triaging of bugs and tasks, and
managing feedback requests in one place.
As users perform exploratory testing, you can get insights from the sessions. View completed exploratory
sessions and derive meaningful insights across all sessions. Get end-to-end traceability such as a breakdown of
the work items created, the work items explored and not explored, session owners, and more.
To learn more, see the following articles:
Install the Test & Feedback extension
Request stakeholder feedback
Provide stakeholder feedback
Microsoft Feedback client
The Visual Studio 2015 Microsoft Feedback client is a downloadable tool that you install on your desktop. It
supports similar features for capturing findings to those provided by the Test & Feedback extension. It doesn't
support creating work items. You can download the tool from Feedback Client for Microsoft Visual Studio Team
Foundation Server 2015.
To learn more, see the following articles:
Get feedback (Work tracking)
Provide feedback with the Feedback client
Set feedback permissions
Related articles
Give reviewers permissions to provide feedback
Default permissions and access set for collaboration tools
Give us feedback, get support
Request stakeholder feedback using the Test &
Feedback extension
Stakeholders can respond to feedback requests for user stories and features generated in Azure DevOps using a
lightweight end-to-end flow based on the Test & Feedback extension. Only users with Basic access can request
feedback. Basic users can provide feedback using the flow described in this topic.
Request feedback
Provide feedback
Voluntary feedback
Track requests
NOTE
This lightweight end-to-end flow is applicable only for web apps and by using Azure DevOps. To get feedback for desktop
apps, or for earlier versions of TFS, use the feedback flow described in Get feedback about the Microsoft Feedback Client.
Request feedback from stakeholders

Request feedback from stakeholders directly from an Azure DevOps work item.
1. Open the work item form for the user story or feature for which you want to request feedback.
2. Open the shortcut menu from the ellipses (...) and choose Request feedback .
3. Type or select the names of the stakeholder(s) you want to send the request to, and optionally add any
instructions or notes that will help them provide meaningful feedback.
4. Choose Send to generate emails to all the selected stakeholders.
NOTE
Teams can request feedback from other team members, such as users having Basic access. Just add their names in the
feedback request form so that a Request feedback email is sent to them. Also see Can users with Basic access respond
to feedback requests?.
Related articles
Provide stakeholder feedback using the Test & Feedback extension
Voluntary stakeholder feedback using the Test & Feedback extension
Track stakeholder feedback using the Test & Feedback extension
Exploratory test and submit feedback directly from your browser
Overview of manual and exploratory testing
Provide feedback using the Test & Feedback
extension
Stakeholders and other users can respond to feedback requests using the Test & Feedback extension in two
ways:
From the link in a feedback request email
Directly from the Test & Feedback extension
Before you start, ensure you have installed the Test & Feedback extension. This is required in order to respond to
feedback requests.
NOTE
Any user with a Stakeholder access can use the Test & Feedback extension in Stakeholder mode. This mode is designed
to allow the widest possible range of users to assist test teams by providing feedback.
Provide feedback directly from a feedback request email

1. Open the feedback request email and choose the Provide feedback link.
2. The Azure DevOps landing page opens to confirm that the extension has been automatically configured
with the feedback request. Choose the icon in the toolbar to launch the extension.
If you are a Stakeholder , you see the Feedback requests page. Read the instructions (if any) in the
feedback form to understand how to give the feedback and what the requestor requires.
If you are a Basic user, you see the Explore work item traceability page showing details of the user
story on which feedback was requested, and the user acceptance criteria (if any).
3. Read any instructions in the email and this page to understand how to give the feedback, and on what
feature.
4. Open the application you need to provide feedback on and begin your feedback. For example, choose
Capture screenshot to take a screenshot.
You can use all the capabilities of the extension such as capturing screenshots, notes, and screen
recordings. For more details, see this topic.
Some browsers may not provide all the capture capabilities. See Supported web browsers for the
extension.
5. When you are done capturing feedback:

If you are a Stakeholder , choose Provide feedback . You can optionally choose to create bugs
and tasks when you submit your feedback. The process is the same as described in this topic.
If you are a Basic user, create a bug or a task.
6. All your feedback captured is shown in the response form, bug, or task. Type a suitable title and,
optionally, select a star rating for the feature you've been testing.
7. Save your feedback. This create a work item in Azure DevOps containing all your feedback.
8. Continue to capture more feedback if required. You can submit multiple feedback responses, bugs, and
tasks for the same feedback request.
9. If you are a Stakeholder :
When you are done providing feedback, go to the Feedback requests page and choose
Feedback requests .
In the pending feedback requests page, mark the feedback request as Completed .
10. Choose the Stop icon to end your feedback session.
Provide feedback directly from the Test & Feedback extension

1. Open the Test & Feedback extension in your browser using the icon in the toolbar.
2. In the Connection settings page, choose Connected mode.
3. Connect to the server and the project or team that is requesting feedback.
4. Open the Feedback requests page to see all your feedback requests from the project or team you
connected to.
5. Select the feedback request you want to respond to and choose View feedback .
6. Read the instructions in the feedback request details page, then choose Provide feedback .
7. Capture and submit your feedback as shown above.
Related articles
Request stakeholder feedback using the Test & Feedback extension
Voluntary stakeholder feedback using the Test & Feedback extension
Get insights across your exploratory testing sessions
View completed exploratory testing sessions and derive meaningful insights at team or individual level, and for
a specific period.
Prerequisites
You must connect to a project. If you don't have a project yet, create one.
You must be added to a project. To get added, Add users to a project or team.
To view or run manual or automated tests, you must have Basic access or higher.
To learn more, see Manual test access and permissions.
1. Open the Recent explorator y sessions page. You can do this:
From the Test & Feedback extension by choosing the "view" icon on the Session timeline page.
From the Test Plans web portal. by opening the Runs page and choosing Recent explorator y
sessions .
2. Explore the Recent explorator y sessions page. It contains three main sections:
Summar y view - shows a graphical breakdown of the work items explored, work items created, session
owners, and the total time for these sessions.
Pivot view - shows a collapsible nested and sortable list of items grouped in different ways.
Details view - shows the work item selected in the Pivot view or a summary of information about a
selection of items.
Get insights from your exploratory testing sessions:

Use the Recent explorator y sessions page to get insights about your app from the information collected
during your exploratory testing sessions.
1. Set the scope for the data . Summary view provides the highest level view of your test results. Use it to
get insights into the overall effort and results of the exploratory testing sessions.
Use the View filter to scope the summary view to all sessions or just your own sessions.
Use the Period filter to scope the summary view to sessions in the period from the last 7 to the last
90 days.
2. Pivot the data on the type of work item . Pivot view lets you to focus on all the work items you
created in your exploratory testing sessions, or just on bugs, tasks, or test cases; and group the results in
different ways.
Use the Pivot filter to group the work items as a nested list based on those that have been explored,
those that have not been explored (requires a query), by the session in which they were created, or by
session owner.
Use the Show filter to show all items; or just bugs, tasks, or test cases.
3. Get deep insights from Details view . Details view gives insights into the items selected in Pivot view.
Depending on the type of item you select, you see the work item as an editable form, or a series of charts.
Select a row in Pivot view to see a summary of all the related information in Details view. For example,
if you have pivoted the list based on sessions, select a session to see a summary of all the information
from the work items in just that session.
Select a child row in Pivot view to display the work item form for that individual item. For example, if
you have pivoted the list based on explored work items, expand a work item and select a child bug,
task, or test case to see the work item form for just that item.
Discover work items not yet explored
Use a query to explore the work items that users have not yet explored.
1. Create a shared query in Azure DevOps that selects work items that can be explored using the Test &
Feedback extension, such as work items in the epic category, feature category, requirement category,
requirement-based suites, or test cases.
You must use a shared query. If this query returns a mix of supported and unsupported work items,
only those in supported categories will be displayed.
2. Use the View and Period filters to scope the view to the type of session (all sessions or just your own
sessions) and the time span (from the last 7 to the last 90 days). Then open the Quer y list and choose
Select quer y .
3. In the Quer y selector dialog, choose the shared query you created earlier.
4. View all the work items returned by the query in Summary view. You see a breakdown of explored and
unexplored work items, work items filed, sessions, and total session duration.
5. Open the Pivot list and choose Unexplored Work Item .
The view now shows only the unexplored work items.

See Also
Use the Test & Feedback extension in Connected mode
Add findings to existing bugs with exploratory testing
Explore work items with exploratory testing
Use the Test & Feedback extension in Standalone mode
Exploratory testing with Microsoft Test Manager
Install the Test & Feedback extension
The Test & Feedback extension helps teams perform exploratory testing and provide feedback. Everyone in
the team, such as developers, product owners, managers, UX or UI engineers, marketing teams, early adopters,
and other stakeholders can use the extension to submit bugs or provide feedback and contribute to the quality
of your product.
Prerequisites
To view or run manual or automated tests, you must have Basic access or higher.
To learn more, see Manual test access and permissions.
Supported web browsers for the extension

The Test & Feedback extension is currently available for Google Chrome, Microsoft Edge (Chromium Only), and
Mozilla Firefox version 50.0 and higher.
Some browser versions do not currently support all the features of the Test & Feedback extension.
F EAT URE C H RO M E M IC RO SO F T EDGE F IREF O X
Capture screenshots with Yes Yes Yes

inline annotations
Capture notes Yes Yes Yes
Capture screen recordings Yes Yes No
Capture page load data Yes Yes No
Capture user actions log Yes Yes Yes
Capture system information Yes Yes No
Create bugs Yes Yes Yes
Create tasks and test cases Yes Yes Yes
Create feedback requests Yes Yes Yes
Export session report for Yes Yes Yes

sharing
F EAT URE C H RO M E M IC RO SO F T EDGE F IREF O X
End-to-end traceability for Yes Yes Yes

work items
Simplified bug and task Yes Yes Yes

tracking and triaging
View and get insights from Yes Yes Yes

sessions
View similar existing bugs Yes Yes Yes
Test app on devices using Yes Yes No

cloud providers such as
Perfecto
Manage feedback requests Yes Yes Yes
For more information, see Visual Studio Marketplace, Azure DevOps tab.
Install the extension

1. Check the list of supported browsers and decide which you want to use.
2. Download and install your chosen browser, if you haven't already, then open it.
3. Go to Visual Studio Marketplace > Test & Feedback and choose Install .
4. Follow the instructions shown to install the Test & Feedback extension in your browser:
If you are using Google Chrome, choose the Install link for Chrome from the above image to
open the Google Chrome web store and follow the instructions to install the extension.
If you are using Microsoft Edge (Chromium), choose the Install link for Edge from the above
image to open the Microsoft Edge Add-ons page and follow the instructions to install the
extension.
If you are using Mozilla Firefox 50.0 and higher, choose the Install link for Firefox from the above
image to open the Firefox Browser Add-ons page and follow the instructions to install the
extension.
You need to install the extension or add-on only once. Afterwards your browser will update it automatically.
Select an exploratory testing mode

1. Open the extension you installed in your browser by choosing the icon.
2. Decide if you want to use the extension in Connected or Standalone mode.
Connected mode
Available to all users of Azure DevOps and TFS 2015 or later:
Users with Basic access or higher: Full capture and create capabilities to submit bugs, tasks, and test
cases. Includes collaboration capabilities such as end-to-end traceability, rich insights across
completed exploratory sessions, simplified tracking and triaging for bugs and tasks, and more.
Users with Stakeholder access: Full capture and create capabilities, except for test cases, to submit
feedback and respond to feedback requests from the team.
Feedback experience is available only in Azure DevOps and TFS 2017 or later.
Standalone mode
Available to everyone. No connection to Azure DevOps is required. Take notes and screenshots with inline
annotations to capture issues. Create bugs and export a session report to share findings.
If you have problems connecting to Azure DevOps, you may find the topic TF31002: Unable to connect useful.
Related articles
FAQs for manual testing
Next step
Exploratory testing with the Test & Feedback
extension in Connected mode
To use the Test & Feedback extension in Connected mode you must connect to an Azure DevOps project. This
automatically configures the extension based on your access level:
Users with Basic access can use the extension to perform exploratory testing, as described below.
Users with Stakeholder access can use the extension to respond to feedback requests or to provide
feedback voluntarily. More details.
Users with Basic or Stakeholder access can use extension to respond to feedback requests sent by the
team by choosing the Provide feedback link in the email. More details.
Prerequisites
To request or provide feedback, you must have Stakeholder access or higher.
To add or modify bugs or other work item types, you must have the Edit work items in this node
permission set to Allow under the corresponding Area Path .
To add new tags, you must have the Create tag definition permission set to Allow .
To learn more, see Set permissions and access for testing.
Connect to Azure DevOps

1. If you want to use Azure DevOps, and you haven't already done so, sign up for a subscription now. Make
sure you create a project when you create your subscription.
2. If you haven't already, install the Test & Feedback extension.
3. Open the extension in your web browser and select Connected mode.
4. Enter the Azure DevOps URL you want to connect to and choose Next .
If you are connecting for the first time, you may be prompted to sign in.
5. After connecting to the server, the extension shows all the collections, projects and teams in that server.
Select the project or team you want to connect to and choose Save .
If there are many projects or teams, use the search textbox to find the one you need.
The extension is now ready to be used in Connected mode. Depending on your access level (Basic or
Stakeholder) you will see the appropriate UI for either exploratory testing or providing feedback. The extension
remembers your selection and remains connected until the session cookies expire or you explicitly disconnect
from the server.
Create bugs or tasks

After you have connected, you are ready to begin testing your app.
1. Start your exploratory testing session.
2. Open the web application you want to test, and start exploring it.
3. When you find an area that has a bug, take a screenshot of any part of the screen, make notes, or record
your actions as a video.
Some browsers may not provide all of the capture capabilities. See Supported web browsers for the
extension.
4. When you are done exploring and capturing information, create a bug or a task.
5. The bug or task form contains all your captured information. It also contains an image action log
describing your interactions with the page (such as mouse clicks, keyboard typing events, touch gestures,
and more) and page load data. Uncheck these options if you do not want to include this data in the bug
or task.
The image action log is the sequence of steps you took that led to the issue. It can be used to
reproduce the issue and understand the context. Page load data provides preliminary information
about the time it takes to load the pages, such as the resource timings and navigation timelines.
6. Enter a title for the bug or task and add any additional notes you require to the description. Then save the
bug or task.
You can also add your findings to an existing similar bug.
7. View a list of all your activities in reverse chronological order in the Session timeline page. It shows all
the screenshots, videos, and notes you've captured, the work items such as bugs, tasks, and test cases
you've already filed, and the work items you've explored.
You can use the extension to explore work items in Azure DevOps.
8. To view a bug or task in Azure DevOps, choose the link in the session timeline.
This opens the work item form in Azure DevOps.
How do I play the video recordings I created with the extension?
Create test cases

The extension lets you create test cases as you explore your application.
1. When you find a scenario where you want to create a test case, choose Create test case .
2. The test case form contains a list of all your actions up to this point while exploring the app (it reads them
from the image action log).
3. Enter a title for the test case and then edit it as required. For example, uncheck the action steps you don't
want to include in the test case, edit the captured text, and add the expected result. Then save the test
case.
4. Continue exploring the application. Create more bugs, tasks, or test cases as required.
End your testing session

1. When you're done, stop your session.
2. If you are using Azure DevOps, TFS 2017, or later version, open the Session timeline page and choose
the "view" icon to see your completed exploratory sessions in Azure DevOps.
Alternatively, open the Recent explorator y sessions list directly in the Runs page of the Test Plans
web portal.
See your exploratory session results

After you file bugs, create tasks, or create test cases, all these show up in the "Recent exploratory sessions" page
in Azure Test Plans.
See how you can view your sessions and get insights.
Exploratory testing with the Test & Feedback
extension in Standalone mode
All teams can use the Test & Feedback extension in Standalone mode. Users don't need an Azure DevOps
subscription or Team Foundation Server connection to use this mode.
Start testing in Standalone mode

1. If you haven't already, install the Test & Feedback extension.
2. Open the extension in your web browser and select Standalone mode.
3. Open the web application you want to explore and start the testing session.
4. When you find an area that has a bug, take a screenshot of the entire screen or any part of it.
5. You can annotate the screenshot using the tools available in the inline annotation toolbar.
6. Make notes about the issue to share with your team, and then save the note.
Create a bug
1. When you have finished capturing information for an issue, choose Create bug .
2. The bug form contains all your captured information. Enter a title for the bug and add any additional
notes you require to the description. Then save the bug.
3. View a list of all your activities in reverse chronological order in the Session timeline page. It shows all
the screenshots and notes you've captured and the bugs you've already created.
End your testing session

1. Continue exploring the application. Create more bugs as you encounter issues with the app.
2. When you're done, stop your session.
The extension automatically creates a session report that contains details of all the bugs created during
the session, and any attachments.
3. The report is saved in the default Downloads folder of your web browser. Share it with the rest of your
team as an email attachment, or copy it to OneNote, Word, or in any other format you prefer.
Next step
Use the extension in Connected mode
Explore work items with the Test & Feedback
extension
Use the Test & Feedback extension to explore existing work items and associate them with a new or an in-
progress exploratory session. After a work item is associated with a session, all new bugs, tasks and test cases
created in the current session are automatically linked to that work item. This enables end-to-end traceability,
and simplifies tracking and management of issues.
You can explore:
Work items belonging to a requirement category, a feature category, or an epic category
Requirements-based test suites and test cases.
You can explore a work item from the Kanban board or from the extension. You can also explore multiple work
items in the same session.
Prerequisites
Explore work items from the Kanban board

1. In the Kanban board, open the shortcut menu of the work item you want to explore, and choose Do
explorator y testing .
2. A banner in the Work hub shows which work item is associated with your session.
3. Launch the Test & Feedback extension. If there are acceptance criteria for the work item, these are shown.
If you have not already started a session, start one now. The work item is automatically associated with
the current or new session.
4. All bugs, tasks, and test cases you create will automatically be linked to the current work item.
Explore work items from the Test & Feedback extension
1. Open the Explore work item page in the extension and search for the work item you want to explore.
You can search using the work item identifier or keywords in the work item title.
2. Select the work item in the search results and choose Explore selected work item .
3. The work item is now associated with the in-progress session. If there are acceptance criteria, these are
shown.
4. All bugs, tasks, and test cases you create will automatically be linked to the current work item.
Explore multiple work items in the same session
To explore another work item, you must first dissociate the current work item from the in-progress session.
1. Open the Explore work item page and choose Change .
2. Associate the new work item with the in-progress session as described above.

See Also
FAQs for manual testing
Add findings to existing bugs with exploratory testing
Add findings to existing bugs with exploratory
testing
To help avoid duplication, the Test & Feedback extension automatically searches for and displays existing bugs,
based on the keywords in the title, as you file a new bug. You can choose to continue creating a new bug or add
your findings to an existing bug.
Prerequisites
1. As you type the title for a new bug, in the background the extension searches for similar bugs that might
be related to the issue you've found and displays a link to the results. Choose this link to see the results
that have similar title keywords.
The form displays 0 Similar if it does not find any matching bugs. In this case, or if you don't see a
"similar" link, you can create a new bug containing your screenshots, notes, and videos as described in
this topic.
2. If you see a bug you want to update, instead of creating a new one:
Select it in the list and choose Edit .
The extension appends all your screenshots, notes, and videos to the existing bug.
Save the updated bug.
3. If, instead, you decide not to update an existing bug, ignore the "similar" link and:
Choose the New bug link to return to the bug details form.
Enter the details for the new bug and save it as described in this topic.
4. Continue exploring your app, filing bugs and tasks, and creating test cases.

See Also
Explore work items with exploratory testing
Voluntarily provide stakeholder feedback using the
Test & Feedback extension
Stakeholders can respond to feedback requests for user stories and features generated in Azure DevOps using a
lightweight end-to-end flow based on the Test & Feedback extension. Only users with Basic access can request
feedback. Basic users can provide feedback using the flow described in this topic.
Request feedback
Provide feedback
Voluntary feedback
Track requests
NOTE
This lightweight end-to-end flow is applicable only for web apps and by using Azure DevOps. To get feedback for desktop
apps, or for earlier versions of TFS, use the feedback flow described in Get feedback about the Microsoft Feedback Client.
Provide voluntary feedback

You can use the Test & Feedback extension to provide feedback voluntarily, even if you haven't received a
specific feedback request.
1. Open the Test & Feedback extension in your browser using the icon in the toolbar.
2. In the Connection settings page, choose Connected mode.
3. Connect to the server and the project or team that is requesting feedback.
4. Start the exploratory testing session.
5. Open the application you want to provide feedback on and begin your feedback. For example, choose
Capture screenshot to take a screenshot.
You can use all the capabilities of the extension such as capturing screenshots, notes, and screen
recordings.
Some browsers may not provide all of the capture capabilities. See Supported web browsers for the
extension.
6. When you are done capturing feedback, Choose Provide feedback .
You can optionally choose to create bugs and tasks when you submit your feedback. The process is the
same as described here.
7. All your feedback captured is shown in the response form. Type a suitable title and, optionally, select a
star rating for the feature you've been testing.
8. Save your feedback. This create a work item in Azure DevOps containing all your feedback.
9. Continue to capture more feedback if required. You can submit multiple feedback responses, bugs, and
tasks for the same feedback request.
10. Choose the Stop icon to end your feedback session.
Related articles
Request stakeholder feedback using the Test & Feedback extension
Provide stakeholder feedback using the Test & Feedback extension
Track stakeholder feedback
All feedback is captured in a Feedback Response work item. You can track feedback, whether captured by the
Test & Feedback extension or the Microsoft Feedback client, through a work item query.
Prerequisites
By default, all project members and users with Stakeholder access can view and run all shared queries. You
can change the permissions set for a shared query folder or shared query. For details, see Set query
permissions.
To add and save a query under Shared queries , you must be granted Basic access or higher. Also, you must
have your Contribute permission set to Allow for the folder you want to add the query to. By default, the
Contributors group doesn't have this permission.
NOTE
Users with Stakeholder access for a public project have full access to query features just like users with Basic access. For
details, see Stakeholder access quick reference.
permissions.

To view feedback, use the Feedback shared query. Select your project and open Boards > Queries . Under
Queries , select All . In the Shared Queries, select Feedback .
This query displays a list of all the feedback responses received. To learn more, see Web portal navigation.
To create a feedback query, follow these steps:
1. Select Boards > Queries and then select New quer y .
2. In the Editor for your new query, enter the following values:
Team Project = @Project

Work Item Type In Group Microsoft.FeedbackRequestCategory
State = Active
3. Select Save quer y and enter a name.
4. Select Run quer y to see a list of active feedback responses for your team project.
5. Select a response work item to see the details of the feedback.
1. Select your project and open Boards>Queries or Work>Queries . To learn how, see Web portal
navigation.
2. In the list of shared queries, select Feedback . This query displays a list of all the feedback responses
received.
Or, create a feedback query with the parameters, as shown.
3. You should see a list of all active feedback responses for your team project.
4. Open the response work item to see the details of the feedback.
Related articles
What is Azure Test Plans?
Request feedback using the Test & Feedback extension
Get feedback
Provide feedback using the Test & Feedback extension
Define a work item query
Get feedback
Once you have working software, you're ready to get feedback from your stakeholders. You can ask reviewers to
provide videos, screenshots, type-written comments, and ratings. Their feedback is captured into work items
that you can review and use to create a bug or suggest a new backlog item.
Before requesting feedback, make sure that you provide stakeholders who'll you request feedback from the
necessary permissions.
NOTE
You can also request feedback from stakeholders for web apps using the Test & Feedback extension. For desktop apps,
you must use the feedback request form documented in this topic and stakeholders must reply using the Microsoft
Feedback Client.
Prerequisites
You must connect to a team project. If you don't have a project yet, create one in Azure DevOps Services.
You must be added to a project as a member of the Contributors or Project Administrators security
group. To get added, Add users to a project or team.
To request feedback, you must be granted Basic access or higher. For details, see About access levels.
To provide or review feedback, you must be granted Stakeholder access or higher.
To view or modify feedback responses, you must have your View work items in this node and Edit work
items in this node permissions set to Allow . By default, the Contributors group has this permission set.
To learn more, see Set permissions and access for work tracking.
NOTE
Users with Stakeholder access for a public project have full access to the Request feedback feature just like users with
Basic access. For details, see About access levels.
You must be added to a project as a member of the Contributors or Project Administrators security
group. To get added, Add users to a project or team.
To request feedback, you must be granted Basic access or higher. For details, see About access levels.
To provide or review feedback, you must be granted Stakeholder access or higher.
To view or modify feedback responses, you must have your View work items in this node and Edit work
items in this node permissions set to Allow . By default, the Contributors group has this permission set.
To learn more, see Set permissions and access for work tracking.
To send feedback requests, the server administrator must configure an SMTP server.
Add the Other links widget to your dashboard

Add the Other links widget to a web portal team dashboard. For details, see Add widgets to a dashboard
Request feedback
To request feedback, you fill out a form that generates an email request to your stakeholders.
1. From the dashboard, choose the Request feedback link from the Other links widget.
2. Add the feedback reviewers. If you don't see the names you want in the browse list, grant them
permissions to provide feedback.
3. Tell your reviewers how to run the app they'll be reviewing.
4. For each area of interest, decide what type of feedback you want. Set the context for the reviewers by
providing enough background information. Add up to four more areas of interest with the add
feedback item link.
5. Send the request.
1. From the dashboard, choose the Request feedback link from the Other links widget.
If the following message appears, you need to configure an SMTP server.
2. Add the feedback reviewers. If you don't see the names you want in the browse list, grant them
permissions to provide feedback.
3. Tell your reviewers how to run the app they'll be reviewing.

4. For each area of interest, decide what type of feedback you want. Set the context for the reviewers by
providing enough background information. Add up to four more areas of interest with the add
feedback item link.
5. Send the request.
Provide feedback
Reviewers launch your application and provide feedback through the free Microsoft Feedback Client.
1. Reviewers who don't have a version of Visual Studio installed can download the feedback client directly
from the feedback request they receive.
Or, they can go to the Visual Studio download site.

2. Reviewers start the feedback session.
3. They launch the app to review from the feedback tool.
4. They begin providing feedback.
5. Reviewers can add screenshots, comments, and file attachments, and even record the feedback session.
Results show up on the lower part of the screen. In this case, you can see the comment that the
stakeholder wrote after attaching the screenshot.
NOTE
Security Note: Unless you stop recording, everything is recorded—all steps that you take as well as anything
you say. If you provide sensitive data such as user names and passwords, you will capture this information in the
recording. However, you can always delete a recording by deleting the image for the recording session that
appears in the feedback tool's text box.
6. Reviewers can modify or even delete parts of their feedback, such as a recording, before they submit
their feedback.
Review feedback
1. Open the Feedback query.
You should see a list of all active feedback responses for your team project.
2. Open a response item and play or save a recording.

3. Or, you can create a bug or backlog item linked to the feedback.
With the feedback experience, you can engage stakeholders frequently to provide continuous feedback.
Interacting with your working apps, your stakeholders can record rich and actionable data that the
system automatically stores in the form of video or audio recordings, comments, and annotated
screenshots. You can then take action on each feedback response by assigning it to a team member or
creating bugs or backlog items to the linked feedback.
Related notes
You can change the audio device or annotation tool using the Settings icon change settings icon on the
Microsoft Feedback Client.
If you access the Microsoft Feedback Client from a remote machine, you can enable remote audio.
You can install the Test & Feedback extension from the Marketplace, Test & Feedback.
Give feedback using Microsoft Feedback Client
You can respond to a request for feedback using the Microsoft Feedback Client. This tool allows you to launch an
application, capture your interaction with it as video and capture your verbal or type-written comments as well.
To support traceability, your feedback is stored in the data store for Azure DevOps Services or an on-premises
Team Foundation Server (TFS).
You can install the install the Test & Feedback extension from the Marketplace, Test & Feedback.
Initiate a feedback session

When you receive an email request for feedback, it contains a link to launch Microsoft Feedback Client, and a
link to install the feedback tool if it is not already installed.
To install Microsoft Feedback Client
You can skip this procedure if you already have Microsoft Feedback Client installed or if you will access the
feedback tool on a remote machine.
1. Open your email request, and then choose the Install the feedback tool link to install Microsoft Feedback
Client.
If you are viewing the email from an internet-based email client, you might need to copy the address
behind the link and paste it into the address bar of your browser.
2. Restart your computer.
To initiate a feedback session from an email request
1. Open your email request, and then choose the Star t your local feedback session link
NOTE
If you are viewing the email from an internet-based email client, you might need to copy the address behind the
link and paste it into the address bar of your browser.
If you're accessing the feedback tool on a remote computer, open the shortcut menu for the Star t your
local feedback session link, and then choose Copy Hyperlink . On the remote computer, choose
Star t , choose Run , paste the hyperlink into the box, and then choose the OK button.
The Feedback Client launches and the Windows Security dialog box appears.
2. Enter the credentials provided to you for connecting with Team Foundation Server, and then choose the
OK button.
Launch the application

The feedback tool opens to the Start page. Launch the application by following the instructions provided.
1. From the Start page, choose the Application link to open, start, or install the application for which you
have been requested to provide feedback.
2. Follow any additional instructions provided to sign in or access the application.
For example, you would choose the http://staging.fabrikamfiber.com/customer.aspx link and then enter
the user name and password provided.
Provide feedback on requested items

You can record your interactions with the application, record verbal comments, enter text, clip and annotate a
screen, or attach a file. Recordings appear as images within the feedback tool's text box.
To review descriptions of items submitted for feedback
On the Provide page, one or more items appear for you to provide feedback. For each item, you can get context
on what's being asked and then you can give feedback free form through video or audio recordings, text,
screenshot, or file attachments. When finished with one item, choose the Next button to move to the next item.
1. On the toolbar, choose the number of the ITEM that you want to review.
2. Review the information provided.
3. Interact with the application, and determine what feedback you want to provide, based on the instructions
for each item's request.
To start, stop, or delete a screen or voice recording
You can change settings defined for the audio device and annotation tool at any time. For more information, see
Change the audio device or annotation tool.
1. To star t recording: Choose one of the icons: Screen & Voice , Screen only , or Voice only .
IMPORTANT
Security Note: Unless you stop recording, all steps that you take and remarks that you make while recording
screen and voice will be recorded. If you provide sensitive data such as user names and passwords, you will
capture this information in the recording. However, you can always delete a recording by deleting the image for
the recording session that appears in the feedback tool's text box.
2. To stop recording : Choose the Stop button.

The recording stops, and an image appears in the text box that indicates the type of recording and the
length of the recording session.
3. To delete a recording : Choose the image for the recording that you want to delete, and then press the
Delete key.
To add text, capture a screenshot, or attach a file
You can add text, capture a screenshot, annotate a screenshot, or attach a file as part of your feedback. You can
perform these operations while you continue to record your feedback.
By annotating screenshots, you can indicate corrections or improvements by adding text or images to the
screenshot that you captured. By default, Microsoft Paint opens automatically when you open a screenshot
image that you captured within the feedback tool. You can also configure another annotation tool to open
automatically whenever you capture a screenshot. For more information, see Change the audio device or
annotation tool.
1. To add text : In the tool's rich-text box, enter the information that you want to include when you submit
your feedback.
You can use the toolbar to format your comment, add a hyperlink, and insert an image.
2. To capture a screenshot : Choose the camera icon, and then select the rectangular area that you want
to capture.
The image appears in the rich-text box.
3. To annotate the screenshot : Double-click the image.
Microsoft Paint, or whichever annotation tool you have configured, opens with the image displayed. To
specify corrections or improvements, perform the following steps:
a. Draw or enter text onto the image.
b. Choose the Save icon, and close the annotation tool.
The image appears within the feedback tool with the changes that you made.
4. To attach a file : Choose the attachment icon, and in the Open dialog box, browse to the file that you
want to attach, and then choose the Open button.
To rate an item and move to the next item
1. (Optional) Choose one or more stars to indicate your overall rating of the item that you have just
reviewed.
2. Choose the Next button to move to the next item to review.
Review and submit your feedback

After you enter your feedback for each item, you can review, make corrections or additions, and then submit
your feedback.
1. Choose the Submit button, which also stops any recordings that you may have started.
2. (Optional) On the Submit page, choose the review feedback link to return to the Provide page for the
first feedback item. Review your feedback for each item and choose the Next button to advance to the
next item.
You can delete or modify any content within the text box for any item.
3. On the Submit page, choose the Submit and close button.
Microsoft Feedback Client closes, and the system creates a feedback response work item which contains
the feedback that you submit with the title, "Feedback Response from YourUserName for
RequestFeedbackItemTitle."
Related notes
You Initiate a feedback request from the home page of your web portal or using the Other links widget from
a team dashboard.
You can change the audio device or annotation tool using the Settings icon change settings icon on the
Microsoft Feedback Client.
If you access the Microsoft Feedback Client from a remote machine, you can enable remote audio.
To record audio, you must have an audio recording device configured on your computer. If you access the
feedback tool from a remote device, you might have to enable remote audio capture.
Requirements to provide feedback
To provide feedback using the Microsoft Feedback Client you must have security credentials that will allow
you to connect to Azure DevOps Services or an on-premises TFS and have the permissions described in Give
reviewers permissions to provide feedback.
Your computer must meet the system requirements for installing Microsoft Feedback Client. For more
information, see the following page on the Microsoft website: Microsoft Feedback Client Download.
Track stakeholder feedback
All feedback is captured in a Feedback Response work item. You can track feedback, whether captured by the
Test & Feedback extension or the Microsoft Feedback client, through a work item query.
Prerequisites
permissions.
NOTE
Users with Stakeholder access for a public project have full access to query features just like users with Basic access. For
details, see Stakeholder access quick reference.
permissions.

To view feedback, use the Feedback shared query. Select your project and open Boards > Queries . Under
Queries , select All . In the Shared Queries, select Feedback .
This query displays a list of all the feedback responses received. To learn more, see Web portal navigation.
To create a feedback query, follow these steps:
1. Select Boards > Queries and then select New quer y .
2. In the Editor for your new query, enter the following values:
Team Project = @Project

Work Item Type In Group Microsoft.FeedbackRequestCategory
State = Active
3. Select Save quer y and enter a name.
4. Select Run quer y to see a list of active feedback responses for your team project.
5. Select a response work item to see the details of the feedback.
1. Select your project and open Boards>Queries or Work>Queries . To learn how, see Web portal
navigation.
2. In the list of shared queries, select Feedback . This query displays a list of all the feedback responses
received.
3. You should see a list of all active feedback responses for your team project.
4. Open the response work item to see the details of the feedback.
Related articles
What is Azure Test Plans?
Request feedback using the Test & Feedback extension
Get feedback
Provide feedback using the Test & Feedback extension
Define a work item query
Give reviewers permissions to provide feedback
You must grant permissions to provide feedback to users that you plan to request feedback from. Reviewers
who aren't members of your team require special permissions to provide feedback using the Microsoft
Feedback Client.
Add reviewers to your team project

1. From the web portal of your team project home page, open the administration context.
If you aren't a member of the Project Administrators group, get added. See Change project-level
permissions. You need to be a member in order to add users and groups to a team project, change
permissions, and grant them access to the web portal.
2. Create a group for your reviewers.
TIP
If you have a lot of reviewers, create an Azure Devops security group to help you manage permissions more
efficiently. To learn how, see Add or remove users or groups, manage security groups.
3. Name your group.

4. Add accounts to your group.
Set permissions so reviewers can provide feedback

Allow reviewers to Create test runs , View project-level information , and View test runs .
Set permissions so reviewers can modify work items
Since feedback is captured in a feedback response work item, reviewers need to be able to modify work items in
the product areas they will review.
1. Open security for the team project.
2. Add the reviews group to the VSO Groups or TFS Groups .

3. Allow reviewers to Edit work items in this node and View work items in this node.
If you want, allow reviewers the ability to modify their feedback

submissions
Sometimes additional ideas occur after reviewers submit their feedback. By providing access to the web portal,
reviewers can revisit and further annotate their feedback submissions.
Azure DevOps Ser vices: Assign the Stakeholder license to accounts that you add to your Reviewer group
On-premises Azure DevOps Ser ver : Add your Reviewer group to the Stakeholder group on the access
levels page. If you don't see this tab, get administrative permissions.
Your reviewers will be able to view and modify only those work items that they create, which includes feedback
responses. The Stakeholder group provides limited access to features and data for those members of your
organization who do not have an Azure DevOps client access license (CAL).
Related articles
Initiate a feedback request
Respond to a feedback request
Work as a stakeholder
Enable remote audio capture
To record audio, you must have an audio recording device configured on your computer, or on a remote
machine if you access Microsoft Feedback Client, Test Runner, or Exploratory Testing from a remote device.
To record audio as part of a feedback or testing session on a remote machine that is running Microsoft Feedback
Client, Test Runner, or Exploratory Testing window, you must configure audio redirection settings on the remote
machine. You must also enable record from this computer when you connect to the remote machine.
IMPORTANT
We recommend that you open Microsoft Feedback Client on your local computer. Redirection will decrease audio quality.
Microsoft Feedback Client does not require you to record audio as part of the feedback session.
To set a default microphone on your local computer

To record audio from your local computer, you must set a microphone device as the default device.
1. Choose Star t, Control Panel .
2. In the Control Panel window, choose the Hardware and Sound link, and then choose Sound .
3. In the Sound window, choose the Recording tab.
4. Select a recording device from the list provided and then choose Set Default .
To enable remote audio capture

IMPORTANT
If you edit the registry incorrectly, you might severely damage your system. Before you make any changes to the registry,
you should back up any valued data on the computer.
1. Choose Star t , choose Run , enter regedit , choose the OK button, and then set the value of the following
registry key to 0 .
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\fDisableAudioCapture
For more information about how to set values of registry keys, see the following page on the Microsoft
website: How to add, modify, or delete registry subkeys and values by using a registration entries (.reg)
file.
2. To connect to the remote machine, choose Star t , choose Run , enter mstsc , and then choose the OK
button.
The Remote Desktop Connection dialog box opens.
3. In the Computer list, choose or enter the name of the computer to which you want to connect, and, in
the User name box, enter your user name.
4. On the Local Resources tab, choose the Settings button.
5. Under Remote audio recording , choose the Record from this computer option button, and then
choose the OK button.
6. Choose the Connect button.
7. Exit and restart whichever client tool that you are using, for example Microsoft Feedback Client, Test
Runner, or Exploratory Testing.
You must restart you client in order for it to register the audio settings.
Related articles
Exploratory testing
Run your tests
Provide feedback using the Microsoft Feedback Manager
Change the audio device or annotation tool
You can change the default settings used by Microsoft Feedback Client for the annotation tool or audio device.
The annotation tool that you set automatically opens when you double-click an image within the feedback tool,
and the audio device is used when you start a Screen & Voice or a Voice only recording. You might want to
make a change if you do not have the default tools available on the computer that you use to provide feedback.
To change a setting, first launch Microsoft Feedback Client. For more information, see Provide feedback.
To change the annotation tool or annotation settings
1. On the toolbar at the top of Microsoft Feedback Client, choose the Change settings button.
2. In the Change settings dialog box, choose the Browse button.
3. In the Open dialog box, navigate to the annotation tool and executable file that you want, and then
choose the Open button.
4. (Optional) Enter any arguments that can be passed to the annotation tool.
For example, %f represents the file name to pass to the tool.
5. (Optional) Select the After taking screenshot, immediately open in the specified annotation
tool check box to enable the annotation tool to open automatic.
6. Choose the Save button.
To change the audio device
1. On the toolbar at the bottom of Microsoft Feedback Client, choose the Change settings icon.
2. In the Change settings dialog box, choose the Change button to change the default audio device.
3. In the Open dialog box, navigate to the audio device that you want, select the Default audio device
check box, and then choose the Open button.
4. Choose the Save button.
Related articles
Provide feedback
About notifications
Notifications help you and your team stay informed about activity that occurs within your projects in Azure
DevOps. You can get notified when changes occur to the following items:
work items
code reviews
pull requests
source control files
builds
For example, you can get notified whenever you or your team resolves a bug or are assigned a work item.
Notifications get sent based on set up rules or subscriptions. Subscriptions arise from the following instances:
Out-of-the-box (OOB) or default
Created by an administrator for a team or group that you belong to
Created by you
Notification types
There are four types of notifications that you can manage in Azure DevOps. See the following table of the
notification types and required permission or role to manage.
N OT IF IC AT IO N T Y P E RO L E REQ UIRED TO M A N A GE
Personal notifications User
Team notifications Team Administrator or member of the Project Administrators

group or Project Collection Administrators group
Project notifications Member of the Project Administrators group or Project

Collection Administrators group
Global notifications Member of the Project Collection Administrators group
Personal notifications
You can manage your personal notifications in the following manner.
View your notifications
Set alerts only for yourself
View and edit all subscriptions
Add a custom subscription
Unsubscribe or opt out of a team or project subscription
For more information, see Manage your personal notifications.
Team and project-level notifications
You can create a subscription for the following categories and select from the following templates.
C AT EGO RY T EM P L AT E O P T IO N S
Build a build completes

a build fails
a legacy XAML build controller or agent's status
changes
a legacy XAML build's quality changes
Code (Git) a commit is pushed

a pull request is created or updated
a pull request my team is a reviewer on is updated
a comment is made on a pull request
Code (TFVC) code is checked in

code is checked in with a policy override
a file with a specific extension is checked in
a file under a specific path is checked in
any code review changes
Pipelines run stage waiting for approval

run stage waiting for Manual validation
Work a work item is created

a work item is changed
a work item is deleted
a work item is restored
a work item is moved from this team project
Artifacts a package is changed
Extension management an extension is modified
Release an approval for a deployment is pending

a deployment is completed
a request for release creation failed
a manual intervention for a deployment is pending
NOTE
You can also create a custom notification subscription for pull requests that are created or updated in a draft state . For
more information, see Custom notification subscription for draft pull requests.
For more information, see Manage team, group, and global notifications.
Global notifications
Global notifications apply to all projects defined for an organization or collection.
Default subscription
The Default subscriptions tab lists all default global subscriptions available. The on a notification
subscription indicates the subscription is a default subscription. View all default notification subscriptions.
Members of the Project Collection Administrators group have permission to enable/disable any default
subscription in this view. Any member of the Project Collection Valid Users group has permission to view
the details of the default subscription. The view and enable options are available in the context menu ( ... )
associated with each individual subscription.
Subscribers
The Subscribers section begins with an empty identity search box. Enter any group, team, or individual to view
the list of subscriptions associated with the specified identity.
All notification subscriptions for the chosen identity are listed in this view. Management options are available
from the context menu ( ... ) associated with each subscription. The on subscription row indicates a default
subscription.
Statistics
The Statistics section shows the most active notification subscriptions and the top event initiators (group, team,
or individual). The statistics are only for the current day and reset at 00:00 UTC. A benefit of these statistics is
identifying unintended high volume subscriptions or event initiators.
Settings
Manage global-level Settings , such as delivery preferences.
The Settings section allows organization-level management by any member of the Project Collection
Administrators group. All teams and groups inherit the Default delivery option setting. This setting, Default
delivery option, isn't explicitly set at the team or group level.
For more information, see Manage team, group, and global notifications.
Permissions for notifications

There are no UI permissions associated with managing email notifications or alerts. Instead, they can be
managed using the TFSSecurity command line tool.
By default, members of the project level Contributors group can subscribe to alerts for themselves.
Members of the Project Collection Administrators group, or users who have Edit collection-level
information permission, can set alerts for others or for a team, within that collection.
Members of the Project Administrators group, or users who have Edit project-level information
permissions can set alerts in that project for others or for a team.
Preferred email address

The preferred email address for your organization profile gets notifications, by default. It's typically the email
address you signed into Azure DevOps with. You can manage this email address via your organization
preferences profile page.
NOTE
Your preferred email address applies across all of your organizations and cannot be changed on a per-organization basis.
Integrating with other services

If your team uses an external service to collaborate—such as Campfire, Flowdock, or Slack—you can configure
notifications to be sent to these services. These services are supported out of the box:
Campfire
Flowdock
HipChat
Slack
Microsoft Teams
You can also use a third-party service like Zapier to send notifications to hundreds of other services. Learn more
about Zapier and Azure DevOps Services integration.
On-premises SMTP server

NOTE
For on-premises Azure DevOps Server, configure an SMTP server for team members to see the Notifications option
from their organization or user profile menu and to receive notifications.
Related articles
Default and supported notifications
Query with group clauses
FAQs
Default permissions and access set for collaboration tools
Azure DevOps data protection overview
About projects and scaling your organization
A project in Azure DevOps provides a place for users to plan, track progress, and collaborate on building
software solutions. A project represents a fundamental container where you can store data and source code.
When you create your project, Azure DevOps automatically creates a team of the same name, which is sufficient
for small organizations. For enterprise-level organizations, it may be necessary to scale up and create more
teams and projects. You can have up to 1000 projects within an organization in Azure DevOps.
The following diagram shows one project and team versus multiple projects and teams in an organization or
collection. This structure allows teams to configure the tools in ways that work for them and complete
administrative tasks at the appropriate levels. As your organization grows, your tools can grow to support a
culture of team autonomy and organizational alignment.
One project + team

Multiple projects + teams
For more information, see Work tracking, process, and project limits and Plan your organizational structure.
Manage work across your organization

When you connect to Azure DevOps, you connect to an organization or project collection. Within that container,
one or more projects may be defined. At least one project must be created to use the system.
You can scale your organization in the following ways:
To support different business units, you can add projects
Within a project, you can add teams
Add repositories and branches
To support continuous integration and deployment, you can add agents, agent pools, and deployment pools
To manage a large number of users, you can manage access through Azure Active Directory
You can scale your on-premises Azure DevOps deployment in the following ways:
To increase performance, you can add server instances
To support different business units, you can add project collections and projects
Within a project, you can add teams
Add repositories and branches
To support continuous integration and deployment, you can add agents, agent pools, and deployment pools
To manage a large number of users, you can manage access through Active Directory
View projects in your organization

View the projects defined for your organization by opening the Projects page.
1. Select Azure DevOps to open Projects .
2. Choose a project from the list of projects.

For more information, see Create a project.
1. Select Azure DevOps to open Projects .
2. Choose a project from the projects list.

Limit visibility of projects
By default, users added to an organization can view all organization and project information and settings.
The Limit user visibility and collaboration to specific projects preview feature for the organization limits
user access in the following ways.
Restricts views that display a list of users, list of projects, billing details, usage data, and more information
accessed through Organization settings .
Limits the set of users or groups that appear through people-picker search selections and the ability to
@mention users.
IMPORTANT
The limited visibility features described in this section apply only to interactions through the web portal. With the REST
APIs or azure devops CLI commands, project members can access the restricted data.
Guest users who are members in the limited group with default access in Azure AD, can't search for users with the
people picker. When the preview feature's turned off or when guest users aren't members of the limited group, guest
users can search all Azure AD users, as expected.
Limit access to organization settings

To limit access to organization settings, enable the Limit user visibility and collaboration to specific
projects preview feature. Users and groups in the "Project-scoped users group" can't access organization
settings. They can only see the Over view and Projects pages and those projects to which they've been added.
NOTE
All security groups are organization-level entities, even those groups that only have permissions to a specific project.
From the web portal, visibility of some security groups may be limited based on user permissions. However, you can
discover the names of all groups in an organization using the azure devops CLI tool or our REST APIs. To learn more, see
Add and manage security groups.
NOTE
All security groups are collection-level entities, even those groups that only have permissions to a specific project. From
the web portal, visibility of some security groups may be limited based on user permissions. However, you can discover
the names of all groups in an organization using the azure devops CLI tool or our REST APIs. To learn more, see Add
and manage security groups.
NOTE
All security groups are collection-level entities, even those groups that only have permissions to a specific project. From
the web portal, visibility of some security groups may be limited based on user permissions. However, you can discover
the names of all groups in an organization using the REST APIs. To learn more, see Add and manage security groups.
Limit visibility within people pickers

Organizations that are connected to Azure Active Directory (Azure AD) can use people pickers. People pickers
support searching all users and groups added to Azure AD, not just those users and groups added to your
project. People pickers support the following Azure DevOps functions:
Select a user identity from a work tracking field, such as "Assigned to"
Select a user or group with @mention in a work item discussion or field, pull request discussion, commit
comments, or changeset or shelveset comments
Select a user or group using @mention from a wiki page
As shown in the following image, start to enter a user in the people picker box until you find a match to the user
name or security group.
WARNING
When you enable the Limit user visibility and collaboration to specific projects preview feature, project-scoped
users can't search for users who were added to the organization through Azure AD group membership, rather than
through an explicit user invitation. We're working on a solution to this behavior. As a work around, you can disable the
Limit user visibility and collaboration to specific projects preview feature.
Users and groups within the Project-scoped users group can only see and select users and groups in the
project they're connected to from a people picker. To scope people pickers for all project members, see Limit
identity search and selection.
View historical data
All project members can view identities that were added to a comment, discussion, or assignment. For example,
everyone in the project (even users with the new restriction) can still see a user's name assigned to a work item
when the user's no longer part of the project. The same is true for @mentions in PRs, comments, discussions,
and more.
Use a single project

We recommend that you use a single project to support your organization or enterprise. A single project
minimizes the maintenance of administrative tasks and supports the most optimized and full-flexibility cross-
link object experience.
Even if you have many teams working on hundreds of different applications and software projects, you can
easily manage them within a single project. A project serves to isolate data stored within it and you can't easily
move data from one project to another. When you move data from one project to another, you typically lose the
history associated with that data.
For more information, see How many projects do you need?.
Add another project
You may want to add another project in the following instances:
To prohibit or manage access to the information contained within a project to select groups
To support custom work tracking processes for specific business units within your organization
To support entirely separate business units that have their own administrative policies and administrators
To support testing customization activities or adding extensions before rolling out changes to the working
project
To support an open-source software (OSS) project
You may want to add another project in following instances:
To prohibit or manage access to the information contained within a project
To support custom work tracking processes for specific business units within your organization
To support entirely separate business units that have their own administrative policies and administrators
To support testing customization activities or adding extensions before rolling out changes to the working
project
Use private and public projects

You can have both private and public projects. You can also change the visibility of a project from private to
public.
Private projects require that you add and manage user access. Users must sign in to gain access to a project,
even if it's read-only access. All project members have access to the project and organization information. For
more information, see Resources granted to project members.
Public projects don't require users to sign in to gain read-only access to many of the following services. Public
projects provide support to share code with others and to support continuous integration/continuous
deployment (CI/CD) of open-source software.
For more information about features and access levels for public projects, see Make a private project public.
Version control support

Git repositories can be browsed and cloned, but only via HTTPS. SSH and GVFS endpoints are unavailable.
Clients like Visual Studio and IntelliJ work with the HTTPS clone URL but don't offer the connected experience
linking to work items and other collateral.
Dashboard widget support

The following dashboard widgets won't display any useful information for non-members.
Assigned to me
Code tile
New work item
Pull request
Query results
Requirements quality
Sprint burndown
Sprint capacity
Sprint overview
Team members
Welcome
Work links
Other links
Structure your project

Use the following elements to structure your project to support your business needs.
Create a Git repository for each subproject or application, or create root folders within a TFVC repository for
each subproject. If you're using TFVC and heading toward a combined project model, create root folders for
different teams and projects, just as you would create separate repos in Git. Secure folders as needed and
control which segments of the repo you're actively using with workplace mappings.
Define area paths to support different subprojects, products, features, or teams.
Define iteration paths (also known as sprints) that can be shared across teams.
Add a team for each product team that develops a set of features for a product. Each team you create
automatically creates a security group for that team, which you can use to manage permissions for a team.
For more information, see Portfolio management.
Grant or restrict access to select features and functions using custom security groups.
Create query folders to organize queries for teams or product areas into folders.
Define or modify notifications set at the project level.
Customize and configure your project

You can configure and customize most services and applications to support your business needs or the way
your teams work. Within each project, you can do the following tasks. For a comprehensive view of which
resources can be configured, see About team, project, and organizational-level settings.
Dashboards : Each team can configure their set of dashboards to share information and monitor progress.
Source control : For each Git repository, you can apply branch policies and define branch permissions. For
TFVC repositories, you can set check-in policies.
Work tracking : You can add fields, change the workflow, add custom rules, and add custom pages to the
work item form of most work item types. You can also add custom work item types. For more information,
see Customize an inheritance process.
Azure Pipelines : You can fully customize your build and release pipelines, and define build steps, release
environments, and deployment schedule. For more information, see Build and release.
Azure Test Plans : You can define and configure test plans, test suites, test cases, and test environments. You
can also add test steps within your build pipelines. For more information, see Exploratory and manual testing
and continuous testing for your builds.
Dashboards : Each team can configure their set of dashboards to share information and monitor progress.
Source control : For each Git repository, you can apply branch policies and define branch permissions. For
TFVC repositories, you can set check-in policies.
Work tracking : You can add fields, change the workflow, add custom rules, and add custom pages to the
work item form of most work item types. You can also add custom work item types. For more information,
see Customize the on-premises XML process model.
Build and release : You can fully customize your build and release pipelines, and define build steps, release
environments, and deployment schedule. For more information, see Build and release.
Test : You can define and configure test plans, test suites, test cases, and test environments. You can also add
test steps within your build pipelines. For more information, see Exploratory and manual testing and
continuous testing for your builds.
Add a team
As your organization grows, you can add teams equipped with configurable Agile tools to meet each team's
workflow. For more information, see the following articles.
Scale Agile to large teams
About teams and Agile tools
Manage a portfolio of backlogs and see progress.
Use delivery plans to scheduled work items by sprint (iteration path) of selected teams against a calendar
view.
Incrementally adopt practices that scale to create greater rhythm and flow within your organization, engage
customers, improve project visibility, and develop a productive workforce.
Structure projects to gain visibility across teams or to support epics, release trains, and multiple backlogs to
support the Scaled Agile Framework.
Connect to a project with other clients

Aside from connecting via a web browser, you can connect to a project from the following clients:
Visual Studio (Professional, Enterprise, Test Professional)
Visual Studio Code
Office Excel
Visual Studio (Professional, Enterprise, Test Professional)
Visual Studio Code
Office Excel
For more information, see Compatibility with Azure DevOps Server versions.
Frequently asked questions (FAQs)

Q: Can I move or transfer a project to another organization or collection?
A: Yes, but not without losing data. You can manually copy resources and leave some behind, or use a third-
party tool, such as OpsHub Visual Studio Migration Utility, which copies data using the REST APIs.
Q: What programmatic tools support projects?
A. See Projects REST API.
You can also use the az devops project CLI.
Related articles
Get started as an administrator
What do I get with a project?
Understand differences between Azure DevOps

Dev Ops Help

Uploaded by

Copyright:

Available Formats

You might also like

Dev Ops Help

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dev Ops Help

Uploaded by

Copyright:

Available Formats

Contents

Wikis, Search, & Navigation

See the following articles for setting other user preferences:

2. Choose Edit profile .

See the following articles for setting other user preferences:

2. Choose Edit profile .

Assign users to a security group

Code: Source control

Create and edit ️

Can view library ️

Use and manage ️

Edit task group ️

Build and Release

Azure Test Plans

P ERM ISSIO N REA DER C O L L A B O RATO R C O N T RIB UTO R O W N ER

List, install, and ️

Save packages from ️

Edit feed permissions ️

P ERM ISSIO N REA DER C O N T RIB UTO R O W N ER

List and restore/install ️

Edit feed permissions ️

Rename and delete feed ️

Notifications, alerts, and team collaboration tools

View the project page, navigate using the project page

Dashboards, charts, reports, and widgets

View team and project dashboards

View team dashboards

Add and configure project dashboards

Add and configure team dashboards

Power BI Integration and Analytics views

Connect from the web portal

For example, to connect to the server named FabrikamPrime , type:

For example, to connect to the server named FabrikamPrime , type:

4. Choose your project, team, or page of interest.

Sign in with different credentials

2. Choose Sign in and enter your credentials.

Visual Studio 2019

Visual Studio 2019

3. Select a project from the list and select Connect .

Visual Studio 2019

User accounts and licensing for Visual Studio

Connect to the web portal, user accounts, and licensing

Refresh the web portal

Differences between the web portal and Visual Studio

Web por tal

Product backlog, Portfolio backlogs, Sprint backlogs, Taskboards, Capacity planning

Start your search with a keyword

Search features, usage, and examples

Search from a different page

Find an organization setting

Find a project setting

Find a user setting

View file history and compare versions

Search re-index requirements

Open the Wiki

Provision a wiki Git repository

How can I go to the Git repository?

Format wiki content