JPD to Azure DevOps: syncing approved ideas to Epics and getting delivery status back
If your product team prioritizes ideas in Jira Product Discovery (JPD) and your engineers deliver in Azure DevOps, you're probably recreating approved ideas as Epics by hand. After that, the Epic moves through delivery and never gets reflected in JPD. I often see this split. Development works in Azure DevOps; other departments move to Jira, and manual tracking becomes a fallback whenever work spans both. Here's what I've learned about connecting the two, including the parts that don't sync cleanly. What happens without a sync Your product team creates an epic in Azure DevOps and copies over the title, the description, and maybe the acceptance criteria. Then engineering takes over. State changes, comments, and linked pull requests stay in Azure DevOps, so product has to open the board to find out whether something shipped. This defeats the point of keeping the roadmap in JPD. Why JPD is harder to integrate than regular Jira You'd expect the Jira Cloud REST API to cover it, since JPD runs inside Jira. It covers part of it. JPD projects are team-managed, so their fields don't share with company-managed projects the way regular Jira fields do. The Jira Cloud API reads and updates JPD ideas as issues, but there's no dedicated public API for JPD-specific artifacts. Insights, views, and the newer roadmap fields sit outside what the standard API gives you. Formula fields don't come through the API at all. The Atlassian-maintained Azure DevOps for Jira app doesn't solve this either. It links development activity to Jira issues, and it doesn't create or sync work items between the two tools. What syncs and what needs work Standard fields sync without trouble: summary, description, status, priority, assignee, reporter, comments, attachments, and labels. Custom fields such as impact and effort scores, RICE values, product areas, and goals sync cleanly, since they're regular custom fields. Insights, views, and roadmap fields need custom scripting, and some aren't fully supported. Formula fields won't sync, because the API never returns them. The connection is easy to establish. Field mapping is where most of the work goes, and 2 problems come up again and again. The first is user mapping. Jira identifies people by account ID, and Azure DevOps uses Entra ID identities, so assignee and reporter need an explicit lookup between the two. Add a fallback for users who only exist on one side. Syncs can break because the default assignee left the company and their account was deactivated. The second is empty fields. A sync that assumes a value is always there fails when a field is left blank in JPD, so handle nulls before you go live. Use case 1: Push approved ideas to Azure DevOps as Epics Idea to Epic handoff Current Setup: Product prioritizes in JPD. Engineering works from an Azure DevOps board. Problem: Approved ideas get recreated as Epics manually, and the scoring context gets lost along the way. Solution: A query-based trigger on the JPD side picks up ideas once they hit an approved status and creates the Epic in the right Azure DevOps project, with score fields carried over. Most teams I talk to don't want every idea pushed across. They want to decide when something crosses over, so the trigger condition matters more than people expect. One idea usually maps to one Epic. JPD doesn't carry a Feature or User Story hierarchy, so any split into Features and stories happens in Azure DevOps after the sync. Use a JQL trigger such as project = ROADMAP AND status = Approved so only ready ideas cross over. A manual "sync this" action may not exist on the JPD idea view, and a query-based trigger also removes the risk of someone syncing the wrong idea by accident. Use the JPD product area field to set the area path on the Epic, so it lands on the right team's board without anyone triaging it. Use case 2: Get delivery status back into JPD Epic state to idea status Current Setup: The idea lives in JPD, and the Epic lives in Azure DevOps. Problem: Product only knows delivery status by asking engineering or opening the board. Solution: Map the Epic's state back to the idea's status, so the roadmap in JPD shows what's shipping. Example mapping for the Agile process template: New → Ready for delivery Active → Implementing Resolved → Waiting for release Closed → Released If your organization uses Scrum, CMMI, or an inherited custom process, your Epic states will differ, so build the mapping from your own process. Decide field by field which side wins when both teams edit the same thing. Status usually flows from Azure DevOps to JPD only, and priority often flows the other way. Going further with pull requests and release gates Some teams want more than a done or not-done flag. One setup I've seen ties Jira story status to Azure DevOps pull request events. A story moves to Code Review when a PR goes up, Ready for QA once the PR is approved, and back to In Progress if QA rejects it. The same logic works at the release level. Azure DevOps moves the linked Jira release through UAT Approved, Security Approved, and CAB Approved as each gate clears, then adds a link to the deployment pipeline once the release goes out. This applies to Jira Software stories and releases, not JPD ideas directly. None of it works out of the box. You write it into the sync rules on both sides, with service hooks on the Azure DevOps side firing the events. The admin rights problem Product and engineering rarely hold admin rights on each other's tools, and I've seen this stall projects completely. At one bank, the Jira admin wasn't an admin in Azure DevOps, and corporate policy blocked direct access between the two systems. Pick a setup where each side authenticates and controls its own configuration. On the Azure DevOps side, that means a scoped PAT or an Entra ID service principal owned by your Azure DevOps admin. Nobody needs admin rights on the other team's system to keep the sync running. Plan for a separate security review too. In most organizations, the person who owns the integration isn't the person who signs off on it, and InfoSec will ask where data is stored, how long it's kept, and how it's encrypted. Have those answers ready before the technical evaluation ends, so the project doesn't stall at the last step. What to check before you pick an approach You have 3 realistic options: Jira Automation plus Azure DevOps service hooks. This is free and works for simple one-way flows. It gets harder once you need two-way updates, attachments, or anything beyond creating the Epic once. Custom middleware on Azure Functions or Logic Apps. You get full control, and you also own every API change on both sides from then on. A third-party integration platform. This is faster to set up, with a subscription cost and less control over the internals. Whichever you choose, check it against these: Bidirectional sync, with direction set per field Support for JPD custom fields, plus a plan for insights and roadmap fields Query-based triggers on the JPD side State mapping that handles your Azure DevOps process template User mapping between Jira account IDs and Entra ID identities, with a fallback Separate admin control on each side, with PAT or Entra ID authentication Scripting for conditional logic such as PR events and release gates Clear error reporting that tells you which item failed and why, plus automatic retries Audit logging, role-based access, and the certifications your security team asks about (ISO 27001 is the usual one) Error reporting is often skipped during evaluation. When a sync fails at scale, you need to see the failing work item and the component that broke without exporting logs to a spreadsheet. If you run Azure DevOps Server on-premises, add one more check: how the tool reaches your server from the Jira Cloud side. That decides whether you need to open inbound access or run part of the integration inside your network. FAQs Can you sync Jira Product Discovery with Azure DevOps? Yes. JPD ideas behave as Jira issues through the Jira Cloud API, so an integration can create Azure DevOps Epics from approved ideas and send state changes back. Standard and custom fields work. Insights, views, roadmap fields, and formula fields need extra work or won't sync. Does Jira Product Discovery have its own API? The regular Jira Cloud REST API reads and updates JPD ideas as issues. There's no dedicated public API for JPD-specific artifacts such as insights or formula fields. Will RICE scores sync to Azure DevOps? RICE, impact, and effort scores sync because they're standard custom fields. You'll need matching custom fields on the Epic work item type in your Azure DevOps process to receive them. Can Jira Automation handle this on its own? It can create an Epic in Azure DevOps through a web request when an idea is approved. Keeping both sides updated after that, including comments, attachments, and state, is where automation rules usually run out. Do I need admin access to both Jira and Azure DevOps? Not if each side authenticates separately. Your Azure DevOps admin sets up a PAT or service principal on their side, your Jira admin handles theirs, and neither needs rights on the other system. Before you build Pull up the JPD fields your product team uses every week and check each one against your sync rules. Then run a test sync on a few ideas and compare the values on both sides before you go live.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 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.How to sync date and time formats between Azure DevOps and Jira?
Jira Cloud and Azure DevOps have different APIs that support different data formats, even for the same type of data. Azure DevOps uses the HTML format, while Jira uses Wiki. When transferring date-time information between both platforms, transformers need to work behind the scenes to convert between both formatting styles. That’s the only way to get coherent data. But, this conversion is not available by default due to the lack of compatibility. So, a third-party tool is needed to bridge this gap. In this article, I’ll discuss how to sync date and time formats between Azure DevOps and Jira Cloud. We'll use a third-party integration tool called Exalate to implement this use case. Use case requirements If your Jira and Azure DevOps instances are hosted in different time zones, and you need to manipulate the date-time fields so that the same date is kept, here is how we do it. Let us assume the two teams are 5 hours apart. Here is what we can do: “Due Date” and “Start Date” are custom date-time fields in Azure DevOps “Start date” is a custom date field in Jira “Due” is the standard due date field in Jira We would like to add 5 hours to the Jira timestamp when they are received in the Azure DevOps instance. Then, we would like to subtract 5 hours from the Azure DevOps timestamp when they are received in Jira. How to use Exalate to sync date and time formats between Azure DevOps and Jira cloud? Exalate comes with an AI-powered scripting engine that allows you to write mapping rules for any connection. It supports the Groovy language, which you can use to write the transformation algorithm for the date-time information. To implement this use case, you need to install Exalate on both your Jira Cloud and Azure DevOps instance. Then, set up a connection in the Script mode. Once connected, click Configure Sync and navigate to the Rules tab, where you’ll set up sync rules. In the Rules tab, you’ll find default scripts for syncing basic fields like summary, description, comments, and attachments. To sync custom fields or behaviors, you’ll need to add your own scripts. The Rules tab is divided into: Outgoing Sync: Defines the information sent from Jira to Azure DevOps. Incoming Sync: Maps the information received from Azure DevOps into Jira. The same exists on the Azure DevOps side. Jira outgoing script replica.customFields."Start date" = issue.customFields."Start date" replica.due = issue.due The script for the data going out of Jira is being fetched from the custom field named “Start date”, while the due date is going over as the replica.due expression. Jira incoming script import java.text.SimpleDateFormat import java.text.DateFormat import java.util.Calendar import java.util.Date def datePattern = "yyyy-MM-dd HH:mm:ss"; DateFormat formatter = new SimpleDateFormat(datePattern); dateString = replica."start" dateString = dateString.replaceAll("T"," ").trim(); dateString = dateString.replaceAll("Z"," ").trim(); date = formatter.parse(dateString); def timestamp = date.time Calendar calendar = Calendar.getInstance() calendar.timeInMillis = timestamp calendar.add(Calendar.HOUR_OF_DAY, -5) def updatedTimestamp = calendar.timeInMillis issue.customFields."Start date".value = updatedTimestamp dateString = replica."duedate" dateString = dateString.replaceAll("T"," ").trim(); dateString = dateString.replaceAll("Z"," ").trim(); date = formatter.parse(dateString); timestamp = date.time calendar.timeInMillis = timestamp calendar.add(Calendar.HOUR_OF_DAY, -5) issue.due = calendar.getTime() The code snippet above allows you to set the datePattern and parsing it through a formatter. It also fetches the timestamp down to milliseconds from the calendar. The calendar.add(Calendar.HOUR_OF_DAY, -5) expression specifies that the timestamp coming into Jira should be at least 5 hours behind the original time obtained from Azure DevOps. Azure DevOps outgoing script replica."start" = workItem."Microsoft.VSTS.Scheduling.StartDate" replica."duedate" = workItem."Microsoft.VSTS.Scheduling.DueDate" This code snippet fetches the start and due dates from the default Microsoft Azure DevOps Server (formerly VSTS or Visual Studio Team System). Azure DevOps incoming script import java.text.SimpleDateFormat import java.util.Calendar import java.util.Date def convertJiraTimeToAdoTime(String dateString){ if(dateString == null) return String inputFormat = "yyyy-MM-dd HH:mm:ss.S" String outputFormat = "yyyy-MM-dd'T'HH:mm:ss'Z'" // Create SimpleDateFormat objects for the input and output formats SimpleDateFormat inputDateFormat = new SimpleDateFormat(inputFormat) SimpleDateFormat outputDateFormat = new SimpleDateFormat(outputFormat) // Parse the input date string into a Date object Date date = inputDateFormat.parse(dateString) def timestamp = date.time Calendar calendar = Calendar.getInstance() calendar.timeInMillis = timestamp calendar.add(Calendar.HOUR_OF_DAY, 5) def updatedTimestamp = calendar.timeInMillis // Convert the Date object into the output format return outputDateFormat.format(updatedTimestamp) // String } // does not set the field String inputDateString = replica.customFields."Start date"?.value workItem."Microsoft.VSTS.Scheduling.StartDate" = convertJiraTimeToAdoTime(inputDateString) inputDateString = replica.due workItem."Microsoft.VSTS.Scheduling.DueDate" = convertJiraTimeToAdoTime(inputDateString) This code snippet converts the incoming date-time information into a string before parsing it as input into the date object. It then fetches the date from the calendar to be 5 hours ahead of the time fetched from the Jira Cloud instance. Once you’re done, review the scripts to make sure everything is in order before publishing the changes. That’s all! Your date-time formats are now in sync between Azure DevOps and Jira Cloud. Using script-based solutions, like Exalate, can seem overwhelming at first, but if done correctly, they can be very effective for your integration needs. Have any specific use case that requires handling different data formats? Just ask our integration engineers for a walkthrough of what’s possible or drop a comment here.
