Support bug intake and status portal for Azure DevOps
Let support agents file bugs straight from a Zendesk ticket, catch duplicates before submitting, and track status without an Azure DevOps license.
I want a bug intake and status portal that my support team can work in without ever opening Azure DevOps or holding a license. It uses Azure DevOps and Zendesk. There are three views: File a bug, My submissions, and a bug detail view.
File a bug is a simple form with title, what happened, steps to reproduce, severity, and affected customer. The agent can prefill it from a support ticket: they type a customer name, email, or keyword, the app searches Zendesk with Search Tickets, and they pick the right ticket from the results. The app then pulls that ticket with Show Ticket and the full conversation with List Ticket Comments, and uses the requester details plus the comment thread to populate the affected customer and the description of what happened. The agent edits the draft before submitting.
Before the form submits, run a duplicate check. Take the title text and any tags on the report, run Query Work Items (WIQL) against the project to find existing bugs with similar title words and matching tags, hydrate the matches with Get Work Items Batch, and show them as a short list of likely duplicates with their current state. From there the agent can either attach to an existing bug, which posts their customer and ticket details onto that bug with Add Work Item Comment instead of creating anything new, or dismiss the suggestions and continue filing.
Filing creates the bug in Azure DevOps with Create Work Item. Stamp the Zendesk ticket number and the submitting agent's email onto the work item so the link back to support survives. Note for the build: work item creation uses a JSON Patch array body, and teams customize the Bug work item type heavily, so read the available fields and severity values with List Work Item Types rather than hardcoding them, and use List Projects so an admin can pick which project the app files into.
My submissions lists the bugs the signed in agent has filed. Find them with Query Work Items (WIQL) filtered on that agent's stamped email, then hydrate the ids with Get Work Items Batch to show title, current state, who it is assigned to, and when it last changed, so nobody has to ask engineering for a status. This is per user: each agent sees only the bugs they reported.
Clicking a row opens the detail view with the full report, refreshed with Get Work Item, and the engineering discussion from List Work Item Comments. The agent can reply into that same thread with Add Work Item Comment, so questions from engineering about reproduction steps or customer impact get answered without anyone leaving the app.
When a bug reaches a resolved state, its row in My submissions and its detail view surface a notify the customer action. That posts an update onto the linked Zendesk ticket with Update Ticket, as either a public reply to the customer or an internal note. Prefill the message from the bug's resolution and let the agent edit it before it sends.
Keep all support facing copy in plain language. Do not expose raw Azure DevOps field names, work item ids, or internal state values anywhere in the interface. Translate them into words a support agent already uses, and label things the way support talks about bugs rather than the way Boards does.
What does this prompt do?
- Turns a support ticket into a filed bug in a few clicks: the agent picks the ticket, and the form fills in the affected customer, what happened, and the conversation history so far.
- Shows likely duplicates before anything is submitted, so your team attaches to the bug that already exists instead of filing a fifth copy of it.
- Gives every agent a personal list of the bugs they reported, with the current status, who owns it, and when it last moved, so nobody has to chase engineering for an update.
- Carries the engineering discussion back to support, and posts a resolution update onto the customer's original ticket once the bug is fixed.
What do I need to use this?
- An Azure DevOps account, and the project your engineering team tracks bugs in
- A Zendesk account with permission to read tickets and post replies
- Nothing extra for your support team: they work entirely inside this app and never need an Azure DevOps license of their own
How can I customize it?
- Choose which project new bug reports are filed into, and which report type they are created as
- Adjust the severity choices and any extra details your engineering team expects on a bug report
- Change how strict the duplicate check is, and which statuses count as resolved for the notify the customer step
FAQs
Do my support agents need an Azure DevOps license?
Will engineering see these bugs in their normal boards?
How does the app know which bugs are mine?
How does the duplicate check work?
Does the customer find out when the bug is fixed?
Can agents talk to engineering from inside the app?
Related templates
Open one board each morning to see which Zendesk tickets are turning hostile, why, and who has been waiting longest.
Work "I think I was hacked" tickets in one place: see each customer's real breach exposure beside their conversation, then note, tag, and reply with confidence.
See which questions your customers keep asking, then record a short avatar explainer for the ones actually worth answering on video.
Reps work their live ticket queue on one screen, get a cited draft answer pulled straight from your documentation, and send it without leaving the app.
A console where reps open a tough ticket, see the three closest past resolutions, and send an approved reply drafted from them.
Look up a customer by name, find the sandbox behind their complaint, and get a plain language explanation of what went wrong, no E2B login needed.
Stop chasing engineering for bug status.
Give your support team one screen to report bugs, spot duplicates, and see exactly where every report they filed has got to.