Integrations / Azure DevOps
User bug reports, filed as Azure DevOps work items
Connect your Azure DevOps organization, choose the project, board and sprint, and every report your users send becomes a work item there: a Bug for bug reports and whatever type you like for feature requests, with the screenshot, the recording and the voice note attached.
Connecting
Paste your organization's URL and a personal access token with Work Items (Read & write) and Project and Team (Read). Work items are created as the token's owner, so a service account's token keeps working when people leave. The token is stored sealed and never shown again. One connection serves every project in your team.
Choosing where reports land
- The project, and the team and area, which decide whose board shows it.
- The iteration: the team's backlog, whatever sprint is current when the report arrives, or a fixed one.
- A work item type for bug reports, and one for feature requests: Bug and User Story, say, or Issue and Epic on the Basic process.
- Tags and a priority for each. A feature request's importance (blocking, important, nice to have) becomes priority 1, 2 or 3 when its type has one.
Brainbox reads your project's process, so the choices match it: Agile, Scrum, CMMI, Basic or your own. When you save, it checks the setup against Azure DevOps without creating anything, so a required field you missed or an area that was renamed shows up then, not on your users' first report.
What the work item holds
- The title from the first line of what the user said.
- The report in the field the type reads it from: Repro Steps on a Bug, Description elsewhere.
- The page, browser, viewport and locale in System Info, where the type has it.
- The marked-up screenshot inline, and the screenshot, screen recording and voice note uploaded as attachments.
- A link back to the report in Brainbox.
The work item is made in one call, fields, attachments and link together, so it is never left half-filled. If a sprint lookup fails because the team no longer exists, the delivery fails and says so rather than quietly dropping the item in the backlog.
When something goes wrong
Every delivery is recorded: sent, with the work item's id and link, or failed, with the reason and a retry. If Azure DevOps rejects the token (it expired, or was revoked), the connection is marked as needing a new one, and nothing is sent through it until someone reconnects.
Running it yourself
The destination is azureDevopsWorkItems() in the source-available @ganeshdole/brainbox-integrations package, for a backend of your own. Set baseUrl for Azure DevOps Server.
import { azureDevopsWorkItems } from "@ganeshdole/brainbox-integrations"
const ado = azureDevopsWorkItems({
organization: "acme",
project: "Web",
workItemType: "Bug",
auth: { pat: process.env.ADO_PAT },
areaPath: "Web\\Checkout",
iteration: { currentFor: "Web Team" },
tags: ["brainbox"],
bodyField: "Microsoft.VSTS.TCM.ReproSteps",
systemInfoField: "Microsoft.VSTS.TCM.SystemInfo",
feature: { workItemType: "User Story", tags: ["feature-request"] },
})Try it before you install it
The button in the corner of this page is the real widget. Report something on this page and it lands in our inbox, the way your users’ reports will land in yours.
Get started