Guide: How to Connect ServiceNow to Azure DevOps with a Fully Configurable, No-Code, 2-Way Sync
Let's talk about integrations. You need them because your business runs on too many different software systems that don't communicate with each other, so people end up working in data silos without a reliable source of truth. So each department ends up dealing with incomplete data or relying on inefficient and unreliable manual data transfer processes. So what are your options? Integrations break data silos, increase the capabilities of the entire software stack, improve overall efficiency, and provide you with real-time visibility and alignment. However integration requests are overflowing the backlogs of every IT department. Does that sound right? If not, let me know in the comments. Integration solutions today are either too basic, or excessively complicated, forcing you to default to a complex and costly solution provided by external consultants or you get to DIY like building an IKEA bedroom set without instructions. Unito is a Microsoft partner with a new integration for https://bit.ly/SNADO-int. What makes it different? It was designed with 2-way sync from the start in the form of a no-code platform that's still fully configurable. So you get 50+ powerful integrations right out of the box, and the ability to deeply customize and adapt them without writing or maintaining code. But you can if you want to. So anyone can sync records in ServiceNow to Azure DevOps work items with real-time 2-way updates between fields. How does it work? Users create low-code 2-way integrations called "flows". The flow represents the connection between ServiceNow and Azure DevOps. You start by selecting a table in ServiceNow and a project in ADO. Then, you choose a flow direction for item creation. Do you want manually created records to automatically add work items in ADO; vice versa; or both? Next, you set rules with an "if this, then that" logic to filter out unrelated records or work items. Typically you would add tags in ADO and only sync work items with those tags, but you can also filter by custom fields or any other native field. Finally, you set up a table of field mappings populated with drop-down menus that include data pulled from ServiceNow and ADO: Here's a longer https://bit.ly/SNADO-Guide. Let me know if you have any questions or comments!Hands on experience with ADAL.js and securing backend with Azure AD
When integrating different systems, you might consider secured them via Azure AD authentication. However, if you are outside the context of Office 365, then you will need to generate a token somehow. In this blog, we show how to configure your Azure AD applications, and how to generate the needed token to make the REST calls. http://www.linkedin.com/redir/redirect?url=https%3A%2F%2Fwww%2Elinkedin%2Ecom%2Fpulse%2Fusing-adaljs-authenticate-against-your-azure-secured-native-iliev&urlhash=S1s7&_t=tracking_anetEarly look at containers in Windows Server, Hyper-V and Azure – with Mark Russinovich
In this show, you'll learn from Mark Russinovich, about the design and architecture of containers and how you can use them. Including the new native container technology in Windows Server 2016 and how this extends to Hyper-V and Microsoft Azure.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?How to Sync Area and Iteration Paths Between Jira and Azure DevOps
Azure DevOps area and iteration paths do not have a direct replica on the Jira side. So to sync information between both systems, the area and iteration path data has to be mapped to a custom field in the Jira issue. For this to work, you need a customizable AI-powered integration solution like Exalate. This solution will help you generate the script for mapping paths and maintaining the relationships between the work item and the issue. What is an Area Path? An area path establishes a hierarchy for work items related to a specific project. It helps you group work items based on team, product, or feature. Organizations working on a product or feature can use area paths to establish a hierarchy between teams at every level of involvement. You can assign the same area path to multiple teams. What is an Iteration Path? An iteration path assigns work items at the project level based on time-related intervals. Teams can share them to keep track of ongoing projects, specifically for sprints, releases, and subreleases. When new work items are added to the Sprint backlog, they become accessible via the existing iteration path. You can add up to 300 iteration paths per team. Sync Area and Iteration Paths: Jira to Azure DevOps Use Case You can create a custom field in your Jira instance to reflect the data from the iteration and area paths. How does this help your organization? Syncing this data gives more context about the teams involved on the Azure DevOps side. It provides context about the timelines and stages of progress for the mapped projects and entities. Primary Requirements Obtaining the right information from the API on both sides. Writing or generating the correct sync rules for both the incoming and outgoing data. Creating triggers to update the custom fields on Jira automatically. Fetching the right string from the area or iteration path. How Exalate Handles Jira to Azure DevOps Syncs Exalate supports one-way and two-way integration between Jira and Azure DevOps as well as with Zendesk, ServiceNow, Salesforce, GitHub, etc. Exalate also supports AI-powered Groovy scripting with the help of a chatbot. Users can also create trigger-based integrations for real-time syncs and bulk operations. To use Exalate, first install it on both Jira and Azure DevOps. Since this use case requires scripting, you need to set up a connection in the Script Mode. To configure the sync, 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 the work item on Azure DevOps. Outgoing Sync (Azure DevOps): Send Area and Iteration Path Details from Azure DevOps to Jira To send out the area and iteration paths from the Azure DevOps work item, use the code below: replica.areaPath = workItem.areaPath replica.iterationPath = workItem.iterationPath The replica retrieves the values of the area and iteration paths from the work item and saves them as a string. On the remote side, you can store the area/iteration path in a custom field using a type string or select list. Incoming Sync (Jira): Set Area Path from Azure DevOps as a Custom Field in Jira Let’s start with the area path. The area path starts with the name of the project. For example, an Azure DevOps project called AzureProject handled by Exalate’s dev team could have an area path: AzureProject\\ExalateDev. To set the area path based on the value received from the remote side text field, use the code below: issue.customFields."Area Path".value = replica.areaPath The issue.customFields."area-path".value retrieves data from the work item and stores it in the designated custom field on Jira. Incoming Sync (Jira) Set Iteration Path from Azure DevOps as a Custom Field in Jira The iteration path shows the name of the project as well as the specific sprint. For example, an Azure DevOps project called AzureProject in the first sprint could have an area path: AzureProject//Sprint1 If you don’t set the value for the Area field in the Sync Rules, Exalate uses the default area that has the same name as the project. To set the iteration path based on the value received from the remote side text field, use the code below: issue.customFields."iPath".value = replica.iterationPath The issue.customFields."iPath".value retrieves data from the work item and stores it in the designated custom field on Jira. Congratulations! You have successfully mapped the area and iteration path to a Jira custom field. If you still have questions or want to see how Exalate is tailored to your specific use case, drop a comment below or reach out to our engineers.
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.
