ServiceEndpointProxy activity on ADO Service Connection
I have an ADO Service Connection which I don't think is being used by any pipelines but I still see regular entries in the usage history like: Type: ServiceEndpointProxy Details: ServicePrincipalSignInAudience I've not been able to find any information about what causes this. What is causing this activity and will deleting the service connection adversely affect anything assuming this is the only thing using it?
DevOps REST API - identity picker (query on list of users)
I'm using DevOps REST API via OAuth 2.0 to populate the fields of work item types. For "identity" fields, such as "System.AssignedTo", I'm having a hard time trying to figure out the best API that allows to retrieve a searchable list of users that mirrors what users see on DevOps website. From the browser inspector I saw the website calls this API, which is not documented: [POST] https://dev.azure.com/MY_ORGANIZATION/_apis/IdentityPicker/Identities as also noted on another discussion. But when I call this API (with the very same request body) from my local server I get a 401 response status code, and HTML content instead of the anticipated JSON. In Microsoft Entra Admin Center, I made sure to include "vso.identity" API permission for my app registration. What am I missing here? If I cannot use this API, what's the best alternative? I saw the https://learn.microsoft.com/en-us/rest/api/azure/devops/ims/identities/read-identities?view=azure-devops-rest-7.0&tabs=HTTP, but when I try to load it on the browser I always get zero results. E.g. https://vssps.dev.azure.com/MY_ORGANIZATION/_apis/identities?api-version=7.0&searchFilter=DisplayName&filterValue=SEARCH_TERM { "count": 0, "value": [] } Also, all the REST APIs I used so far are on https://dev.azure.com. How is https://vssps.dev.azure.com any different? Can I call APIs on a different host with the same OAuth access token?
How to create a active bugs trend chart
Hi everybody! I'd like to create a Active bug trends, like this: However, everytime that I try to create this, I always have this result My chart always sum the quantity of bugs, not the trend When I try to setup my chart, I have this screen Note that I have the option Count. My question is: How to create a active bug trend chart? I try this documentation but, no success: https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/manage-bugs?view=azure-devops#monitor-bug-status-assignments-and-trends Thanks for Advice Mauricio
Visual Studio Sign In Issues (Restricted IE)
Hi, Does anyone know how to get around the VS sign in issue when your organisation restrict the use of Internet Explorer for external sites? I get a blank screen as connection is blocked. Changing the default brower in VS doesnt seem to effect the sign page either. ThanksFree Extension: Generate AI Development Prompts from Azure DevOps Work Items — Verity Framework
Hi Azure DevOps community, I wanted to share a free extension we just published to the Visual Studio Marketplace: the Verity Framework ADO Extension. **What it does** It adds a "Verity Prompt" tab to your work items. When you populate five custom fields on a User Story or Delivery Item, the extension generates a structured prompt ready to paste into Claude Code, Cursor, or GitHub Copilot Workspace. The five fields: - VF Intent — the problem and who experiences it - VF Value — the expected outcome - VF Appetite — time/resource ceiling (not an estimate) - VF Trust Criteria — Gate 2 hardening requirements - VF Failure Scope — Narrow / Moderate / Broad / Systemic **Why it matters** Most engineers using AI tools start from a blank context or a vague task description. The extension carries the team's planning judgment — including production risk level and hardening requirements — directly into the implementation context. It also includes field validation that flags vague Trust Criteria, incorrectly formatted Appetite values, and solution-framed Intent statements before generating the prompt. **Setup** About 20 minutes. You add five custom fields to your existing User Story work item type (no new work item type required). Full instructions are in the extension tab. **Install** Search "Verity Framework" on the Visual Studio Marketplace or visit idearoost.com/verity for the full framework context. Free. No subscription required. Happy to answer questions about the field definitions or the setup process. — Jacques Steward, IdeaRoost
DevOps Wiki: How to enable download of attachment
Hello, I do have a git based wiki in ADO with the following structure: | ---- REAGME.md | ---- .attachments | ---- config.xml Within README.md I want to reference config.xml in a way that: 1. enforces the file to be downloaded and not opened 2. ensures a meaningful file name proposal for the download For "common" markdown this would be something like: ... [Config](./.attachments/config.xml?download=true&name=config.xml) ... unfortunately ADO performs some URL-encoding to this relative link and tries to find a file named: - ./attachments/config.xml%3Fdownload%3Dtrue%26name%3Dconfig.xml This file cannot be found (why should it, such a file does not exist) My questions are: 1. How to properly format the relative link in ADO markdown to make the attachment downloadable 2. How to properly format the relative link in ADO markdown to define the attachments name Exclusion: - The answer "Use an absolute link like https://..../" is not an option as no-one will ever be able to maintain this across multiple branches Thank you in advance 😉
Is it possible to define and visualize new metrics (e.g. ratios) in dashboard widgets in Azure DevOp
I am creating some Azure DevOps Dashboard visuals. Some of the metrics I want to create do not seem to be included in the built in Azure DevOps widgets. As two particular examples: (i) I am using a Velocity widget. But instead of showing the sum of Story Points planned and completed, I just want to show the ratio completed/planned for each iteration (i.e a small change, that does not seem to be supported by the Configure Widget options)https://i.stack.imgur.com/0BHVL.png (ii) I want to show the ratio (Count of WorkItems with priority 1 or 2) / Count of all WorkItems The "Chart for Work Items" widget provides something close, allowing a visual of a chosen type (Bar, Pie etc) showing the Count or Sum of a field from a query, grouped by another field. But this doesnt allow for a ratio to be calculated. I cannot find any other widget type (built in, or within the Marketplace) that allows calculation of such ratios. I am sure that there is a way to define brand new widgets, to add to the marketplace, but that is more than I would want to undertake. Also I know that it is possible to pull data from DevOps into a tool like PowerBI, but I would prefer to stay in DevOps if possible. Is there something I am missing, where in DevOps it is possible to define/visualize new metrics like ratios?Integrating Azure DevOps with Jira Service Management: Real-World Use Cases
If your development team works in Azure DevOps while support operates in Jira Service Management (JSM), you're probably dealing with manual ticket updates, information silos, and delayed responses. This friction slows down ticket resolution and creates unnecessary back-and-forth between teams. You can integrate both systems to automate data exchange and keep everyone on the same page. In this post, we'll explore why this integration matters, common use cases I've seen from teams using both platforms, and the key features you should consider when setting up your integration. Why Integrate Azure DevOps with Jira Service Management? When you integrate Azure DevOps with JSM, ticket escalation becomes automatic. A critical bug reported in JSM creates a work item in Azure DevOps with complete context—error logs, customer details, priority level, and all relevant information. Status updates sync bidirectionally. Your support team sees development progress without switching tools. Developers get full customer context without leaving Azure DevOps. The real benefits: Eliminate copy-paste errors Real-time visibility into work status Faster incident resolution Clear audit trails for SLAs and post-mortems Each team stays productive in their preferred environment Without integration, support agents need to check Azure DevOps regularly for updates to relay to customers. This creates delays, introduces errors, and wastes time on both sides. Common Use Cases for Azure DevOps + JSM Integration I have worked with hundreds of teams integrating these platforms. Here are the most common scenarios: 1. Incident and Bug Escalation This is probably the most common use case. Critical bugs reported in JSM automatically create high-priority work items in Azure DevOps with error logs, affected user details, and complete customer context. As developers update the work item, adding comments, changing status, or resolving the bug, those changes flow back to JSM automatically. Support agents can keep customers informed without constantly asking the dev team for updates. Use Case: Current Setup: Support uses JSM for customer tickets. Development uses Azure DevOps for bug tracking. Problem: Manually updating both systems is time-consuming and error-prone. Solution: Two-way sync ensures bugs and updates flow automatically between both systems. 2. Feature Request Management When customers submit feature requests through JSM and they get approved, they automatically flow to Azure DevOps as backlog items with inline images, custom fields, attachments, and more. When development completes the feature, the original JSM request closes automatically and notifies the customer. Use Case: Current Setup: Product managers collect feature requests in JSM. Developers track work in Azure DevOps. Problem: Manually creating work items for approved requests takes time, and context gets lost. Solution: Approved JSM requests automatically create Azure DevOps work items with full context. 3. Multi-Platform Sync for MSPs A central JSM instance can route tickets to different Azure DevOps projects based on work item type. This works especially well for MSPs managing multiple clients. You can connect your JSM instance with multiple client Azure DevOps environments while keeping data completely isolated per client. Use Case: Current Setup: An MSP uses one JSM instance. Multiple clients use separate Azure DevOps environments. Problem: Routing tickets manually to the right client's Azure DevOps is inefficient. Solution: Conditional routing based on customer tags or custom fields automatically sends tickets to the correct Azure DevOps project. 4. Post-Merger System Integration When two companies merge, one might use JSM for service management while the other uses Azure DevOps for development and QA. Rather than forcing everyone onto a single platform immediately, you can connect both systems to let teams continue using their existing tools during the transition. Use Case: Current Setup: Merged company with different tool stacks. Problem: Forcing immediate migration disrupts workflows. Solution: Integration bridges the gap while you plan a longer-term consolidation strategy. Key Features to Consider When Choosing Your Integration Approach Bidirectional vs. Unidirectional Sync Bidirectional sync is essential when both teams need to update shared information like status, priority, and comments. Updates flow both ways automatically without sync conflicts. For some use cases, you might only need one-way sync. For example, JSM → Azure DevOps for escalations where only support creates tickets, but developers provide all updates. Selective Filtering You don't want to sync everything. Look for solutions that let you sync only tickets meeting specific criteria: priority levels, labels, custom fields, or status values. Example filters: Only sync JSM tickets with "escalate-to-dev" label Only sync Azure DevOps bugs tagged "customer-reported" Only sync high and highest priority items This keeps Azure DevOps boards focused on actionable work rather than cluttered with routine requests. Field Mapping Flexibility JSM and Azure DevOps use different field structures. Your integration needs to handle transformations between JSM's field structure and Azure DevOps work item fields without losing data. Common mappings: JSM Status → Azure DevOps State JSM Priority → Azure DevOps Priority Custom fields require explicit mapping rules Scalability The solution should handle your current ticket volume and grow with your organization. Look for reliable performance, error handling, retry mechanisms, and the ability to add more integrations as your needs expand. Security and Compliance Essential security features: Encryption in transit and at rest OAuth or Basic authentication ISO certification Role-based access controls For MSPs: Complete data isolation between client environments Audit logging for compliance requirements Conflict Resolution You need clear rules for what happens when both sides update the same field simultaneously. Common approaches include last-write-wins logic or timestamp-based priority. Technical Implementation Approaches Webhooks + REST APIs Azure DevOps Service Hooks, combined with JSM REST API, provide real-time bidirectional sync. This is the recommended approach for most teams. The flow works like this: Change happens in Azure DevOps Service Hook triggers webhook Integration middleware receives a webhook Middleware calls the JSM REST API to update the ticket The same flow works in reverse for JSM → Azure DevOps updates. Custom Middleware For complex requirements, custom middleware gives you maximum flexibility: Custom field transformation logic Complex routing rules Conditional synchronization Workflow orchestration Error handling and retry logic Common technology stacks include Azure Functions, Logic Apps, or custom Node.js/Python microservices. Third-Party Integration Platforms Many teams opt for dedicated integration platforms rather than building from scratch. These platforms offer pre-built connectors for both JSM and Azure DevOps, significantly reducing implementation time. What third-party platforms typically provide: Pre-configured connectors that understand both JSM and Azure DevOps data structures out of the box Visual or scripting interfaces for setting up field mappings, filters, and sync rules with or without writing code Managed infrastructure so you don't need to host and maintain your own integration servers Built-in error handling and retry logic that handles API failures automatically Audit logging and monitoring dashboards for tracking sync activity and troubleshooting issues Support for complex scenarios like multi-project routing, conditional logic, and custom field transformations Regular updates to keep pace with API changes in both platforms When to consider third-party platforms: You need to get integration running quickly without significant development effort Your team lacks in-house expertise in API integration You want managed infrastructure rather than maintaining your own servers You need support and documentation for troubleshooting You plan to integrate multiple tools beyond just JSM and Azure DevOps You require complex field mappings and conditional routing that would be time-consuming to build Trade-offs to consider: Recurring subscription costs vs. one-time development investment Less control over the exact implementation compared to custom solutions Dependency on the platform's feature set and release cycle Data flows through a third-party service (though reputable platforms offer strong security and compliance) Most platforms available in the Azure DevOps marketplace or Atlassian marketplace offer free trials, allowing you to test their capabilities before committing. Choose the right approach considering the above trade-offs and advantages I have discussed. Good luck! Let's discuss if you have anything specific in mind related to this post.Azure Devops - Best way to create a burndown chart for an Epic
Hi, What is the best way to create a chart that would should the burndown (or burnup) of Story Points completed on User Stories under one or more Epics? I have never been able to do this within Azure DevOps itself. Have just picked up PowerBi and can't do it there either! Regards M
Help with Burnup / Burndown ?
I'm trying to build a burnup or burndown by feature. I know that's not a native feature in ADO right now, so I built it using tags. Even though most of the stories were written (and some completed) well in advance of May 17, I created the tag on the 17th, and it appears they're being plotted against the last changed date. Am I doing something wrong, or is this known behavior?
