Integrating ServiceNow with Azure DevOps: Use Cases That Actually Show Up in Practice
I have been working in the integration space for quite some time. Though I work as a Content Manager, I am always curious to see how users handle integrations between multiple systems. Usually, the service desk runs on ServiceNow, and the build happens in Azure DevOps. But these tools aren't inherently connected, and someone has to manually relay information between them. So, the records never show consistent data. You need a way for the data to pass automatically between them. Even within this setup, a lot of scenarios come forth: from a single ServiceNow instance connecting to a single Azure DevOps org, up to companies running six or seven orgs off a shared service layer. Here's the full range of use cases I keep seeing, organized by what they're actually solving. Native Tools vs. a Dedicated Integration Layer Before the use cases, it's worth being clear on when you need more than what's built in. ServiceNow's IntegrationHub can push data through flows, and there's a spoke for looking up and creating basic Azure DevOps work items. Azure DevOps also has a native extension for pipeline-to-change-management syncing. These native options work fine when the integration is simple: one team, clean field mappings, developers on hand to maintain it. They start to struggle once you're crossing org boundaries, crossing company lines, or dealing with fields and states that don't line up between the two systems. At that point, a dedicated integration layer that handles the mapping and keeps each side's access separate is usually the better fit. Core Sync Use Cases 1. Sync ServiceNow Requests to Azure DevOps User Stories Current setup: Support or service teams work in ServiceNow. When a request needs development, someone has to get it onto an Azure DevOps board as a User Story. Problem: A person creates the work item by hand, copies the request details, and checks back later for updates. When the work item closes, the ServiceNow request often doesn't reflect that, so the requester never hears back. The two records aren't linked. Solution: A trigger, filtered by assignment group, category, or a manual send action, creates the User Story automatically. The link between the two records gets stored on both sides. Updates to the work item flow back to the request, and closing one side closes the other. 2. Sync Comments and State Back to ServiceNow Current setup: ServiceNow holds the ticket the requester sees. Azure DevOps holds the actual dev work. Problem: When the work item moves in Azure DevOps, the ServiceNow ticket's state doesn't follow. Comments the dev team adds stay in Azure DevOps, so the service team keeps pinging developers for status. Solution: As the work item's state changes, it updates the linked ServiceNow ticket. Comments from the dev side sync back too. The service team sees progress without opening Azure DevOps or chasing anyone. 3. Sync ServiceNow Catalog Items to Azure DevOps Current setup: Users order catalog items in ServiceNow. Fulfilling some of them takes real development work tracked in Azure DevOps. Problem: The catalog task sits in ServiceNow while the work happens somewhere the requester can't see. Someone bridges the two manually, and the catalog item's status stops meaning anything. Solution: The catalog item creates a matching work item in Azure DevOps with the request details attached. As the dev team works, status and comments sync back, so the catalog task shows real progress and closes when the work item does. 4. Cut Duplication Between Incidents and User Stories Current setup: Incidents land in ServiceNow. Some get tracked as User Stories in Azure DevOps so the dev team can work them alongside the rest of the backlog. Problem: The same information gets documented twice, updated twice, and the two records drift apart over time. Solution: Incidents create linked User Stories automatically, with comments and status syncing both ways. Update one side and the other reflects it, so nobody's working the same incident twice without realizing it. 5. Sync Bugs with Attachments Across Multiple Orgs Current setup: Bugs get raised in ServiceNow, often by a separate first-line support team, while product teams work across several distinct Azure DevOps orgs. Problem: Recreating bugs by hand loses attachments and context, and there's no clean way to route each bug to the right org out of several. When a bug's fixed, ServiceNow doesn't hear about it. Solution: A bug creates a matching Bug work item in the correct Azure DevOps org, attachments included. Status and comments flow back to ServiceNow when it's resolved. Each connection runs independently, so the first-line team stays in ServiceNow without needing access to the other side. 6. Project-to-Hypercare Handover Current setup: During a build, everyone works in Azure DevOps. Once it goes live and moves into maintenance, incidents and requests need to land in ServiceNow, sometimes a brand-new instance. Problem: Teams used to living in Azure DevOps now need a maintenance process in ServiceNow, with no link back to the developers who built the thing. Solution: Incidents raised during hypercare reach the dev team in Azure DevOps, and fixes flow back to ServiceNow. Because the connection is independent of either team's existing workflow, you can add it without disrupting how people already work. 7. Bidirectional Field and Lifecycle Sync Current setup: A demand owner in ServiceNow needs to track a Feature as it moves through scoping, active work, testing, and deployment in Azure DevOps. Problem: If effort, status, and assignment only live in Azure DevOps, the ServiceNow record goes stale. Fields on each side use different names and values, so a raw pass-through just creates mismatches. Solution: Key fields sync in both directions with explicit mappings. From Azure DevOps: iteration path, change reference, estimated effort, assignment, and lifecycle status. From ServiceNow: design documents, portfolio area, demand type, and requirement details. As the Feature moves through its stages, the ServiceNow record updates in real time. 8. Multiple Azure DevOps Orgs to a Central ServiceNow Instance Current setup: Each business unit runs its own Azure DevOps org, often from an acquisition or separate supplier setup. A central ServiceNow layer needs visibility across all of them without forcing a shared workflow. Problem: Without a sync, someone manually pulls data between systems and chases updates. It doesn't scale as orgs get added. Solution: Each org gets its own connection, configured independently, feeding the central ServiceNow instance. Every org keeps its own states and fields while leadership gets a single view across all of them. 9. Selective Field Sharing Between Separately Hosted Environments Current setup: One side runs cloud-hosted, the other on-prem or in a regulated environment, and neither can open full network-level access to the other. Problem: A basic integration either oversprays fields it shouldn't, or requires a network connection security won't approve. Each side wants control over exactly what leaves its environment. Solution: Outgoing and incoming rules configured independently on each side let each admin decide what leaves and what gets accepted. The two environments sync over a secured channel without either side getting direct access to the other's system. 10. Handling Closed and Read-Only Tickets Cleanly Current setup: ServiceNow access controls block updates to closed incidents. Your sync runs across tickets through their full lifecycle, including closure. Problem: A basic sync throws errors every time it tries to write to something already closed. Solution: Filter closed tickets out of the sync entirely so they never trigger a write, or let the errors surface where your team can see and review them. Which approach you pick is a team decision, not a technical constraint. 11. MSP Routing by Assignment Group Current setup: An MSP runs ServiceNow as its operational layer. Clients work in their own delivery tools, some in Azure DevOps, some elsewhere. Manual handoffs work for a couple of clients and fall apart past a handful. Problem: An engineer resolves an incident and forgets to update the client's system. A comment added on one side never reaches the other. Status shows "in progress" on one side long after it's resolved on the other. As client count grows, the gap between what your team knows and what clients see widens. Solution: An automated rule sends each incident to the right client system based on the ServiceNow assignment group. Set a filter (for example, database issues route to one client's system, network issues to another), and connections run independently with no crossover between clients. The original incident reference gets written into the client ticket, and status values map across cleanly. A couple of related patterns worth knowing: Internal notes can be filtered separately from customer-facing updates, so only what the client should see crosses over. A new client typically reuses your existing ServiceNow authentication, so onboarding is closer to registering their system and setting a routing rule than rebuilding the integration from scratch. 12. Conditional Escalation from Multiple ServiceNow Instances Current setup: Several ServiceNow instances feed a single Azure DevOps org. Only tickets that genuinely need developer attention should reach the board. Problem: Escalating everything floods the board with tickets the dev team shouldn't be handling. Solution: A conditional trigger escalates only tickets meeting a specific condition, so agents push what actually qualifies and everything else stays put. Multiple instances can each feed the same Azure DevOps org under their own trigger logic. 13. Demand Management to Feature Delivery Current setup: A demand process runs in ServiceNow end to end: submission, review, approval, and an approved Requirement. The build happens in Azure DevOps as a Feature, through scoping, active work, testing, deployment, and closure. Problem: Once a Requirement's approved, there's no automatic handoff. Someone recreates the Feature by hand and keeps both sides updated manually. The demand owner can't see effort, status, or assignment as work progresses, so the Requirement goes stale. When the Feature closes in Azure DevOps, the Requirement stays open until someone remembers to close it. Solution: A bidirectional sync connects the full flow. Feature creation: A Requirement creates a Feature automatically, carrying demand context (design sign-off, demand reference, portfolio area, stakeholders, description) so developers get what they need without opening ServiceNow. Field sync: Updates flow both ways, each field mapped to a specific direction. Azure DevOps to ServiceNow: iteration path, change reference, effort, priority, assignment, lifecycle state. ServiceNow to Azure DevOps: the demand and design fields above. Lifecycle feedback: As the Feature moves through its stages, effort, status, and assignment feed back into the Requirement in real time. Closure: When the Feature closes, the linked Requirement closes with it, and the demand gets marked fulfilled. ServiceNow stays the system of record for demand, Azure DevOps for execution, and each side keeps authority over what it owns. What Actually Makes These Work A few capabilities show up across almost every use case above: Attachment sync. Bugs and incidents depend on screenshots and logs. If attachments don't carry over, developers end up back on email. Custom field mappings. Out-of-the-box mappings only go so far. Real setups need custom fields like portfolio area or demand type mapped explicitly, with values transformed, not just copied. State mappings. ServiceNow states and Azure DevOps states don't share vocabulary. Map them explicitly, and decide upfront which side is authoritative when a state changes after creation. Selective sync. Filter by assignment group, area path, work item type, or a custom field. Fewer records crossing means less to govern and less risk of leaking internal data across a boundary. Security and access. For most Azure DevOps admins, this comes down to what gets checked in a security review anyway: Entra ID or OAuth over shared credentials, role-based access, audit logging, and real isolation between connections when multiple clients or companies are involved. For a single team with clean, one-direction mappings, a native option usually covers it. Once you're crossing orgs, crossing companies, or running a full demand-to-delivery flow with real field transformations, that's when a dedicated integration layer kind of becomes necessary. Let's discuss whether any of these match what you're dealing with, or if you've hit an edge case that isn't on this list.Syncing Multiple Azure DevOps Orgs to One ServiceNow Instance Without Forcing a Shared Workflow
If your organization runs more than one Azure DevOps org, whether from an acquisition, a spun-up subsidiary, or business units that never consolidated onto one instance, you already know the visibility gap. Central ServiceNow has no idea what's happening in any of them unless someone checks manually. Your team ends up pulling status updates by hand, chasing changes across orgs, and reconciling what got closed where. That works well for a couple of orgs, but it falls apart past that. Why a Shared Workflow Usually Creates a Bigger Problem Migrating everyone onto a single Azure DevOps org would close the visibility gap on paper. Each org's area paths, iterations, states, and processes took years to get right, and a forced migration undoes all of it. A sync layer between each Azure DevOps org and your central ServiceNow instance closes the same gap without touching how any individual org works day to day. Each org keeps its own configuration. ServiceNow ends up with a rolled-up view across all of them. Common Use Cases Post-Acquisition Org Sprawl Current Setup: A company acquires another company, or runs several business units, each with its own Azure DevOps org and its own way of working. Problem: Central ops has no single view across orgs, and checking each one by hand doesn't scale past a few teams. Solution: Connect each Azure DevOps org to the central ServiceNow instance separately, each with its own sync rules. ServiceNow gets one rolled-up view, and no org has to change how it works. Bi-Directional Status Sync Between Delivery and Support Current Setup: Support logs incidents in ServiceNow. Development tracks the corresponding work in Azure DevOps, sometimes across several orgs. Problem: Support has to ask developers for status or check Azure DevOps boards directly, and developers end up relaying the same update twice. Solution: Sync status, comments, and priority both ways, so an update in either system shows up automatically on the other side. Field-Level Control Per Org Current Setup: Each business unit or subsidiary has its own rules about what data can leave its Azure DevOps org. Problem: A single shared integration with one set of mapping rules risks exposing fields an org never agreed to share outside its own boundary. Solution: Give each org's connection its own outgoing rules, so a subsidiary decides exactly which fields leave its Azure DevOps org, field by field. Handling Closed and Read-Only Work Items Current Setup: ServiceNow blocks writes to closed incidents through ACLs, and Azure DevOps can hit a similar restriction on closed or read-only work items. Problem: A sync that keeps trying to write to a closed item throws the same error repeatedly, and the real problems get buried under the noise. Solution: Filter closed and read-only states out of the sync, or let the errors surface if operations wants visibility into them. What to Evaluate When Choosing an Approach A few criteria matter more than others once you're running this across multiple orgs. Decentralized configuration: does each Azure DevOps org get its own connection and its own rules, or does everything route through one shared setup? Filtering: can you scope the sync with something like WIQL queries on the Azure DevOps side, by area path, iteration, work item type, or tag? Field mapping: does it handle the difference between ServiceNow's field structure and Azure DevOps work item fields without dropping data? Common pairs are ServiceNow State to Azure DevOps State, ServiceNow Priority to Azure DevOps Priority, and ServiceNow Assignment Group to Azure DevOps Area Path. Custom fields usually need explicit mapping rules. Conflict handling: what happens when both sides update the same field at the same time, and what happens with closed or read-only items specifically? Security: Entra ID or OAuth authentication, PAT management per org, role-based access, audit logging, and whatever compliance certifications your security team asks for during review. Direction: bidirectional where both teams update shared fields, one-way where only one side should ever write. Technical Approaches Service Hooks and REST APIs Azure DevOps Service Hooks paired with the ServiceNow REST API give you sync in both directions. A change in Azure DevOps triggers a Service Hook, which calls the ServiceNow API to update the record, and the same flow runs in reverse. This is the most direct route if you're comfortable building and maintaining the webhook logic yourself. Custom Middleware For anything more complex, custom middleware gives you full control over field transformation, routing, and error handling. Azure Functions, Logic Apps, or a small Node.js or Python service usually does the job. The trade-off is maintenance. You own the retry logic, the error handling, and every update when either platform changes its API. Dedicated Integration Platforms Plenty of teams skip building this from scratch and use a dedicated integration platform instead. These typically come with pre-built connectors for both Azure DevOps and ServiceNow, a way to configure field mapping and filters without writing much code, and managed infrastructure so you're not hosting your own sync server. What they usually cover: Pre-configured connectors that already understand both platforms' data structures Visual or scripting configuration for field mapping and filters Managed infrastructure, so nothing runs on your own servers Built-in retry and error handling for API failures Audit logging for tracking what synced and when Support for multi-org routing and conditional logic out of the box The trade-off runs the other way: a subscription cost instead of a one-time build, less control over the exact implementation, and your data passing through a third party's infrastructure. For teams running more than 2 or 3 orgs against one ServiceNow instance, this usually ends up being less overhead than maintaining custom middleware long-term. Every org here has probably solved a version of this differently. Curious what's worked for you, especially with 3 or more Azure DevOps orgs feeding into one ServiceNow instance, and which part of the setup gave you the most trouble.
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?
Free 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, IdeaRoostIntegrating 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.Optimizing Azure DevOps Jira Integration: 5 Practical Use Cases for DevOps Teams
Many teams rely on Azure DevOps (ADO) for development and Jira for project or product management. While each tool is powerful on its own, things often get messy when work items, statuses, and updates live in separate systems. Integrating the two platforms can remove a lot of friction. Below are six common use cases I have seen from real teams, with concrete problems and solutions to make the connection between Jira and Azure DevOps work smoothly. 1. Keeping User Stories and Bugs in Sync Challenge: Teams use Jira for user requests and Azure DevOps for development tasks. Manually updating both systems is tedious and error-prone. Solution: Enable two-way synchronization so that changes in Jira automatically reflect in Azure DevOps and vice versa (including comments and status updates). This keeps bugs and stories aligned without duplicate work. “Before we integrated Jira with Aure DevOps, I spent too much time manually updating task statuses in both systems. Now, with the automatic sync, my team is focused on actual coding work instead of managing project statuses across platforms.” — DevOps Engineer 2. One-Way Sync for Project Management–First Teams Challenge: Some organizations plan and track everything in Jira but manage code exclusively in Azure DevOps. Developers only need the essentials pushed across. Solution: Use a one-way sync from Jira → Azure DevOps to bring over metadata like titles, statuses, sprints, and due dates. Developers see the context they need without cluttering both systems with manual updates. “We rely on Jira for all project planning and management, but the developers need a clean workspace in Azure DevOps. A one-way sync from Jira to ADO helps us keep things efficient and ensures developers always have the latest information without double entry.” — Product Owner 3. Creating Jira Tickets from Azure DevOps Tasks or Bugs Challenge: External partners or stakeholders may only work in Jira Service Management to manage tickets. Developers in Azure DevOps often need their work mirrored for transparency. Solution: Configure automated ticket creation in Jira when certain ADO tasks are tagged. Both teams can track progress in their preferred tool without duplicating effort. “We use Azure DevOps internally, but our external stakeholders only work in Jira. Automating the creation of Jira tickets based on Azure DevOps tasks or bugs has made collaboration seamless and ensured no work is lost in translation.” — DevOps Lead 4. Syncing Epics, Features, and Work Items Challenge: High-level epics might live in Jira, while features and tasks are managed in Azure DevOps. Without integration, visibility across systems is fragmented. Solution: Sync epics and features so Jira provides portfolio-level visibility, while Azure DevOps remains the system of record for detailed development work. This keeps roadmaps and execution aligned. “Tracking epics in Jira while managing the technical work in Azure DevOps used to cause us to lose visibility. Now, everything from high-level epics to individual tasks is in sync, so we always know where we stand.” — Azure DevOps Product Manager 5. Managing Multiple Jira Projects with One Azure DevOps Project Challenge: Large organizations often run multiple Jira projects (by teams or business units) but only one Azure DevOPs project for development. Syncing everything consistently is tough. Solution: Map multiple Jira projects to a single Azure DevOps project, syncing only the key data (titles, statuses, sprints, custom fields). This creates a unified development view without losing project-specific details. “We have multiple teams using different Jira projects, but we consolidate all development work into a single Azure DevOps project. Syncing across these platforms used to be a nightmare, but now everything stays aligned, and we’re able to track all initiatives in one place.” — Azure DevOps Engineer 💬 Have you integrated Jira with Azure DevOps in your team? What worked well, and what challenges did you run into?azure-pipelines-agent on NixOS
I am trying to install azure-pipelines-agent on NixOS, because I want to use nix in my pipeline. I am finding this to be very difficult; the scripts like installdependencies.sh do not support NixOS as a distribution. Is there a known solution or workaround for this, or is it something that may be supported in the future?How to sync sprints between Atlassian Jira and Microsoft Azure DevOps?
Teams involved in a sprint need to be able to exchange information in real time. This will keep all stakeholders and team members in perfect sync. Let’s say the connection is between a team of developers handling work items in Azure DevOps and the IT team using Jira Cloud for service management. To make all updates on one system reflect on the other one, both Jira Cloud and Azure DevOps need to be connected. In the absence of native integration solutions, tools like Exalate can bridge the gap between both platforms. Let me show you how teams can sync sprints between Jira and Azure DevOps. What to consider when syncing sprints between Jira and Azure DevOps? The first thing to bear in mind when syncing Azure DevOps and Jira is security. Considering that both sensitive data will be flowing between the systems, there should be measures to keep the information safe at rest and in transit. Protocols like tokenization, pseudonymization, and firewalls will keep data secure from unauthorized users. Other features like authentication, endpoint detection, and role-based access controls can bolster your security. With security nailed down, pay attention to the flexibility of the integration solution. As the number of tickets increases, the integration should be able to handle the network demands. Due to the dynamic nature of sprints, the tool connecting Jira Cloud and Azure DevOps should also have the scalability to handle an increase in ticket volumes. Another thing to check for is customization. The more sync options and custom connectors available, the broader the application of use cases. How to sync sprints between Jira and Azure DevOps? Assuming you want to sync a Jira sprint with Azure DevOps. Let’s break down what this entails from a technical standpoint. The connection should support data synchronization between standard fields (comments, attachments, etc.) and custom fields. If a sprint gets created in Azure DevOps, it should be automatically replicated on the Jira side with the same information. Issues created in Jira should be channeled to the correct sprint with the iteration path value from Azure DevOps. A custom field named “Team” (Azure DevOps side) should sync to a custom select field called “ADO Team” (Jira side). If any new values are added to the custom field on the Azure DevOps side, these should also be dynamically created on the Jira side. Exalate also supports AI-powered Groovy scripting for setting up syncs between Jira and Azure DevOps. You can use it to set up a two-way integration as well as event triggers for real-time sync and bulk operations. First, install it on both Jira and Azure DevOps. Follow this step-by-step Getting Started guide to connect both of them. This use case can only work with the Exalate Script Mode, which allows you to configure the sync however you want. Open Exalate in your Azure DevOps dashboard, go to the connection you want to edit, and click on the “Edit connection” icon. You have two options: Outgoing sync (on the Azure DevOps side) refers to the data being sent over to Jira. Incoming sync (on the Jira side) refers to the data to be received from Azure DevOps. Here is the code to control what fields and entities go out from Azure DevOps as part of the sprint [Azure DevOps Outgoing sync]: def res = httpClient.get("/<<project_name>>/<<team_name_in_ADO>>/_apis/work/teamsettings/iterations",true) def flag = 0 int i = 0 for (;i<res.value.size(); i++){ if (res.value[i].path == replica.iterationPath){ flag =1 break } } if (flag == 1){ replica.customKeys."sprint_name" = res.value[i].name replica.customKeys."sprint_start" = res.value[i].attributes.startDate replica.customKeys."sprint_end" = res.value[i].attributes.finishDate } The code snippet uses httpClient to fetch the iteration path and uses the flag to assign the name of the sprint (sprint_name), the start date (sprint_start), and the end date (sprint_end). Let’s check out the code to control what’s coming into the Jira Cloud project in the sprint [Jira Cloud Incoming Sync]. def list = httpClient.get("/rest/agile/1.0/board/3/sprint") int flag = 0 for (int i=0; i<list.values.size(); i++){ if (list.values[i].name == replica.customKeys.'sprint_name') flag = 1 } String startDate, endDate; if (flag == 0){ if (replica.customKeys."sprint_start"){ startDate = replica.customKeys."sprint_start".trim() startDate = startDate.replaceAll("Z",".000+05:00").trim(); } if (replica.customKeys."sprint_end"){ endDate = replica.customKeys."sprint_end".trim() endDate = endDate.replaceAll("Z",".000+05:00").trim(); } def res = httpClient.post("/rest/agile/1.0/sprint", "{\"name\": \"${replica.customKeys.'sprint_name'}\", \"startDate\": \"${startDate}\", \"endDate\": \"${endDate}\", \"originBoardId\": boardId}") } def res = httpClient.get("/rest/agile/1.0/board/"Board id"/sprint") for (int i=0; i<res.values.size(); i++){ if (res.values[i].name == replica.customKeys.'sprint_name') issue.customFields.Sprint.value = res.values[i].id } Similar to the Azure DevOps incoming sync snippet, this code fragment fetches the sprint startDate and endDate as customKeys. The httpClient uses POST and GET methods to point to the path or the board containing the sprint name. Congratulations! You have successfully synced your Jira sprint with Azure DevOps. Triggers for the Sync Azure DevOps users can use the Work Item Query Language to configure triggers in Exalate. [Work Item Type] = 'Task' AND System.TeamProject = 'SprintMarch' This triggers the synchronization of any work item (task) in the project named “SprintMarch”. On Jira Cloud, triggers are available via Jira Query Language. project = SprintMarch AND labels = sprint This trigger starts the synchronization if any issue in the project “SprintMarch” has been updated with the label “sprint”. If you still have questions or want to see how Exalate is tailored to your specific use case, discuss your use case with us.Jira Service Management and Azure DevOps Integration: Optimize ITSM and Development Workflows
This article dives into how integrating Jira Service Management (JSM) with Azure DevOps can improve ITSM and development workflows. Let’s face it, businesses can no longer ignore the friction that comes from siloed support and dev teams. Integration, when done right, brings real-time updates, better visibility, and a smoother customer experience. For such integrations, you need tools that help you connect these multiple platforms together. Integration isn’t about one side changing its behavior to meet the needs of the other. It’s about combining strengths, working together, and reducing waste of time and resources on both sides. Exalate connects teams within and across companies by providing a scalable, reliable, and AI-assisted integration solution, eliminating the need to switch between multiple ITSM systems. How does Exalate work? Exalate works as a dedicated app on each system you want to integrate. Each tool admin stays in control. You decide what goes out and what comes in. Exalate is a script-based integration solution. It’s Groovy-based scripting engine allows the flexibility to implement deep integration between Jira and Azure DevOps. Got an edge case that doesn’t quite fit in the standard mold? Bring it on. It’s also available for other systems like Salesforce, ServiceNow, Freshdesk, Zendesk, and more. To make scripting faster (and more approachable), it also provides AI Assist. You describe your sync logic in plain language, and it turns it into dynamic sync rules, right inside the Exalate admin console. Replica and Triggers Exalate allows you to define sync rules that hold what data gets shared and how it maps across systems. Sync rules have a replica. A replica is a copy of an issue/work item that holds the data you want to share. Each integrating side has incoming and outgoing sync rules. In Jira, the outgoing sync will define what information should be transferred to Azure DevOps, and the incoming sync will decide how you map the information coming from Azure DevOps. Triggers kick off syncs automatically, based on conditions written in native query languages like JQL (Jira Query Language) or WIQL (Work Item Query Language). Some common use cases that you can implement. First Use Case: Support Escalation to Dev When a customer raises a ticket in JSM, some of those need to be escalated to the dev team in Azure DevOps, either as Bugs or Features. Map request types from JSM to work item types in Azure DevOps e.g., ‘Report a bug’ → Bug | ‘Suggest a feature’ → Feature Sync status and priority between both platforms. This ensures both teams stay aligned as tickets progress Triggers Used When the project name is SUPP and the request type is a bug or feature, send the ticket over to Azure DevOps. Second Use Case: Product Support Flow The product team creates epics and user stories in Azure DevOps. These entities on the project board are unidirectionally synced to Jira Cloud as epics and stories. The relation hierarchy between Azure DevOps and Jira is maintained. For instance, ‘Relations’ in Azure DevOps are mapped as ‘Issue links’ in Jira. Statuses are synced between Jira Cloud and Azure DevOps to reflect accurate progress. Integrate Azure DevOps and Jira: Get Started Integrating Jira and Azure DevOps is not only a tech decision, it’s a business strategy. With Exalate, you can tailor the integration to your workflow, your logic, and your comfort level. Got a unique use case? Think Exalate might be the answer to your scattered support processes and manual ticket escalations? Drop a comment below, or if you’d rather chat one-on-one, book a call with us. Let’s make your integration work for you, not the other way around.
