Reference · built on requestConnectorWork & ticket management

Azure Boards

Work items, WIQL queries, area and iteration paths, and comments from Azure Boards through the Azure DevOps REST API and service hooks.

Request accessPricing ↗

About

Azure Boards is the work tracking service in Azure DevOps. A project holds work items such as bugs, tasks, and user stories, each with fields, a full revision history, links, tags, and comments. Queries are written in the work item query language, WIQL. The Work Item Tracking REST API answers under https://dev.azure.com/{organization}/{project}/_apis/wit/ with an api-version such as 7.1.

Through Fibric, an operator runs a WIQL query, reads the matching work items, receives service hook events such as workitem.updated, and proposes a field change, a comment, or a link. You approve each proposal; the change goes in once, with a record of the fields before and after.

This is a reference listing. It documents what Fibric would read from Azure Boards and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Work items by id with fields, relations, and links, through the Work Items list and get operations
  • Query results through POST /_apis/wit/wiql with a WIQL string, returning flat, tree, or oneHop results as ids with an asOf time
  • Saved queries and query folders in a project, and the fields each work item type uses
  • Area and iteration hierarchies through classification nodes, and work item type categories such as requirement and bug
  • Revisions and updates of a work item, giving its full history
  • Comments on a work item, with mentions and reactions
  • Service hook events workitem.created, workitem.updated, workitem.commented, workitem.deleted, and workitem.restored, posted as JSON to an HTTPS endpoint

Proposed actions

  • Target capability: propose a field change such as System.State or System.AssignedTo through PATCH /_apis/wit/workitems/{id} as a JSON Patch document, checked first with validateOnly=true
  • Target capability: propose a comment through POST /_apis/wit/workItems/{workItemId}/comments
  • Target capability: propose a link between two work items, or a System.Tags change, through the same PATCH operation
  • Target capability: propose a new work item through the create operation with at least a title and the fields its type requires
  • Target capability: propose several updates in one call through PATCH /_apis/wit/$batch, where a failed request does not stop the others

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Chase work items stuck in a state

    The operator runs a WIQL query for items whose System.State has not changed during the iteration and proposes a comment to the assignee for your approval.

    With Action Follow-up

  • File a bug from a support escalation

    When a ticket points at a defect, the operator proposes a Bug with the ticket summary in the right area path and a link back to the ticket.

    With Escalation Packet, Ticket Triage

  • Hold changes during a freeze

    On workitem.updated the operator checks the iteration and tags and proposes reverting a State move made inside a declared freeze window.

    With Change Freeze

  • Summarize the sprint for the weekly review

    The operator reads the iteration's work items and their revisions since the last review and drafts the summary with each item's url.

    With Weekly Review

Requirements

  • An Azure DevOps organization and project, addressed as https://dev.azure.com/{organization}/{project}
  • Scope vso.work to read and query, and vso.work_write to create, update, and comment on work items
  • Membership in Project Collection Administrators or Project Administrators to create service hook subscriptions
  • A public HTTPS endpoint for service hooks; webhooks cannot target localhost or special-range addresses
Authentication
An OAuth 2.0 authorization with scope vso.work for reading and querying and vso.work_write for creating and updating work items; every call carries an api-version query parameter such as 7.1.

Limits

  • A global consumption limit of 200 TSTUs per sliding five-minute window delays requests, then blocks them with HTTP 429 and a TF400733 message
  • Service hook payloads can be set to Minimal or None, in which case the connector must call back for the work item's fields
  • WIQL returns work item ids and urls only; fields come from a second call to the Work Items operations
  • Higher rate limits require assigning the Basic + Test Plans access level to the integration identity

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Azure Boards ↗

Questions and answers

Which work item events can a service hook send?
Five events under publisher tfs: workitem.created, workitem.updated, workitem.commented, workitem.deleted, and workitem.restored. Each subscription targets one HTTPS URL, sends JSON, and can carry the full resource, a Minimal set of key fields, or None. Subscriptions are created in Project settings under Service hooks, or programmatically.
How are work item fields updated?
With a JSON Patch document sent as PATCH https://dev.azure.com/{organization}/{project}/_apis/wit/workitems/{id}?api-version=7.1 and Content-Type application/json-patch+json. Each operation names a path such as /fields/System.State. An op of test on /rev guards against a stale revision, and validateOnly=true checks the change without saving.
What does the rate limit look like?
Azure DevOps meters consumption in throughput units, TSTUs. The global limit is 200 TSTUs in any sliding five-minute window. Responses carry Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset before delays begin; blocked requests return HTTP 429 with a TF400733 message.
Ask about Azure Boards

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Azure Boards through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy