Azure DevOps Boards
Azure Boards data arrives through your existing Azure DevOps connection. When work item access is granted, we combine your boards data with the commits and pull requests from the same organization to measure how planned work turns into delivered software.
This page describes the boards data specifically. For connecting Azure DevOps, permissions for repositories and pipelines, and the full scope reference, see the Azure DevOps page.
Enabling Work Item Access
Boards data requires the Work items (read) scope, vso.work. It is optional — omit it if you do not use Azure Boards, and we collect repository and pipeline data only.
Include the work items scope when you authorize
When an administrator consents to our Microsoft Entra enterprise application, accept the Work items (read) scope along with the others. This is the read-only option; the alternatives (vso.work_write, vso.work_full) add write access, which we never request.
Give the connecting account access to each project
Scopes define the maximum access a token can have. Actual access is bounded by the permissions of the account that consents, so the account you connect with must be able to read the projects whose boards you want analyzed. An account in the Project Collection Service Accounts group sees the whole organization; a least-privilege service account only sees the projects you add it to.
Confirm area and iteration path visibility
Reading area paths and iteration (sprint) paths requires the Project and team (read) scope, vso.project, plus project membership. Without it, work items are collected but cannot be rolled up by team or sprint.
Reconnect if you previously connected without the scope
Scopes are fixed at the time of consent. If you connected before enabling Azure Boards, reconnect Azure DevOps from Settings > Sources so the new token includes vso.work. We then backfill your historical work items.
Data Collected
We collect work item metadata and its revision history. We do not collect work item descriptions, comment bodies, or attachments.
| Area | Data we collect | Azure DevOps APIs |
|---|---|---|
| Identification | Work item ID, organization, project, work item type (for example, user story, bug, task, epic), and title | Work Items, Projects |
| State | State, reason, resolved reason, board column and done flag, blocked flag, and the deleted flag | Work Items |
| Classification | Area ID and path, iteration (sprint) ID and path, and tags applied to the work item | Work Items, Classification Nodes |
| Estimation | Story points, effort, size, original estimate, completed work, remaining work, and scheduled start and target dates | Work Items |
| Triage fields | Priority, severity, risk, time criticality, value area, business value, activity, discipline, triage state, bug found in environment, and bug root cause | Work Items |
| People | The user who created, activated, assigned, resolved, closed, and last changed the work item | Work Items, Graph |
| Timestamps | Created, activated, resolved, closed, state changed, and last changed times | Work Items |
| History | Every field revision, so we can reconstruct how a work item moved through its states over time | Reporting Work Item Revisions |
| Links | Parent and child links between work items, and artifact links to commits, branches, and pull requests | Work Item Links, Reporting Work Item Links |
Work item titles are encrypted at rest. For the full, provider-independent reference, see Data Collection.