I work for Exalate, and I run support and services here, so most of what I write comes from tickets I've actually sat with. This one's about Jira Product Discovery (JPD), and a challenge I keep seeing product teams struggle with.
JPD is where your product team collects ideas, scores them, and decides what's worth building. The problem is that the context behind an idea usually lives somewhere else. The customer who asked for it is a record in Salesforce. The engineers who'll build it work in Azure DevOps or Jira Software. Your product team ends up switching tools just to figure out who wants what and whether it shipped.
Why the Jira API Doesn't Fully Cover This
You'd expect Jira's own API to handle this, since JPD sits inside Jira. It doesn't, not entirely.
JPD projects are team-managed, and team-managed fields don't share with company-managed projects the way regular Jira fields do. There's also no dedicated public API for JPD. The regular Jira Cloud API reads and updates JPD ideas as issues, but insights, views, and the newer roadmap fields sit outside that.
Atlassian's own community forum flags this as a known limitation. Support threads land on the same answer every time: keeping fields in sync between projects through the API alone doesn't really work, and automations are the workaround.
What I See Teams Do Instead
Without a sync, someone on the team recreates the idea as an Epic in Azure DevOps by hand. Title, description, maybe the acceptance criteria if there's time.
Then it starts drifting. An engineer working on that Epic updates status, adds comments, links pull requests, and nothing reaches back to JPD. Product ends up opening Azure DevOps directly just to check if something shipped. This defeats the entire point of tracking a roadmap in JPD in the first place.
What Actually Syncs
JPD ideas behave like regular Jira work items, so the standard fields move without any extra setup: summary, description, status, priority, assignee, reporter, comments, attachments, labels.
Custom fields matter more in JPD than in most Jira projects. Impact and effort scores, RICE values, product areas, goals- these live in custom fields, and Exalate syncs those too.
A few fields need more care. Insights, views, and roadmap fields need custom scripting, and formula fields don't come through the Jira API at all, so they won't sync regardless of the tool. Check field availability before you build anything around them.
Use Case 1: Pulling Customer Context Into an Idea
The product team prioritizes ideas in JPD. The customer context behind each one sits in Salesforce. Essentially: who asked for it, what market they're in, who owns the account, & such.
With a bidirectional sync, that context lands on the idea itself. You see the customer organization, their market, and the point of contact inside the JPD view. When the point of contact changes in Salesforce, the idea updates too.
It runs the other way as well. Your account team sees every feature a customer has requested inside Salesforce, along with where each one stands in JPD: requested, approved, implementing, waiting for release, released. Sales doesn’t need to ping product for status updates, and product stops digging through Salesforce to find out who wanted what.
If several Salesforce cases roll up into one piece of work on the Jira side, the mapping logic is close to what I laid out in How to Sync Multiple Salesforce Cases to One Jira Epic. Same principle, just applied to ideas instead of standard issues.
Use Case 2: Pushing Roadmap Items to Azure DevOps
An idea maps to an Epic in Azure DevOps in most setups I've seen. If your ADO team splits that Epic into Features and stories afterward, that split happens on their side. JPD doesn't carry that hierarchy.
RICE scores and impact tags sync cleanly in almost every case. A custom formula field or a heavily used Insight view is where I'd script and test before promising anyone it works.
Status flows back too. One workflow I've built for a customer ties Jira story status directly to ADO pull request events: the story moves to Code Review the moment a PR goes up, Ready for QA once that PR is approved, and back to In Progress if QA rejects it. At the release level, the same logic runs in reverse, with the release moving through UAT Approved, Security Approved, and CAB Approved as each gate clears.
None of that is automatic out of the box. It has to be written into the sync rules on both sides. Once it's there, the roadmap in JPD reflects what's actually shipping.
The Access Problem This Also Solves
One bank I've worked with hit a wall before they even got to field mapping. Their Jira admin wasn't a super-admin in Azure DevOps, and corporate policy blocked direct access between the two systems.
A node-based setup gets around this, since neither side needs credentials on the other's system to keep syncing. If your project has stalled waiting on an access request just to test a connector, this is usually why, and it's worth raising early.
Setting This Up
The shape is the same for both connections, Jira to Salesforce or Jira to Azure DevOps.
Create the connection between the two systems and authenticate each side. Each side runs its own node, so your product team never needs Azure DevOps admin rights, and your engineering team never needs Jira admin rights.
Your sync trigger decides which items sync. On the Jira side, that's a JQL query, for example, JPD ideas marked as approved. On Salesforce, it might be opportunities tied to a feature request.
Write the field mappings and any custom logic with Exalate's Groovy scripting engine, then test on a handful of items before you publish anything live.
A Few Things Worth Knowing Upfront
JPD doesn't have a dedicated public API. The regular Jira Cloud API covers ideas as issues, but not insights or formula fields.
You can't sync an individual idea to Azure DevOps manually from JPD's own screen, since Exalate’s Sync Panel doesn't appear on the Idea view. A JQL-based trigger picks up ready ideas on its own instead.
RICE, impact, and effort scores sync fine because they're standard custom fields. Formula fields don't, because they never reach the Jira API to begin with.
Where This Leaves You
If your product team runs JPD and the people who'll build the work sit in Salesforce or Azure DevOps, pull up the fields you actually rely on and check each one against what Exalate can sync before you commit to the build. Standard and custom fields are straightforward. Insights, views, and roadmap fields need a closer look and some scripting.
If you've run into a similar gap with JPD, or you've solved it a different way, I'd genuinely like to hear how in the comments.
