The synchronization completed successfully and no errors occurred, but there was no noticeable improvement in the formatting in Azure DevOps.
After testing, we reverted the change.
We tested both the Jira-side HTML conversion and Azure DevOps-side processing based on the HTML/Markdown Conversion Guide, but were unable to achieve preservation of paragraphs and line breaks in Azure DevOps.
Question
For a Visual Connection (Beta):
What is the recommended approach for preserving Description formatting from Jira Cloud → Azure DevOps?
Is additional processing required on the Azure DevOps side?
Does the standard Description → Description mapping override a scripted assignment to replica.description?
Are there any known limitations of Visual Connections regarding HTML/Markdown conversion?
Any examples for preserving paragraphs and line breaks would be appreciated.
You’ve run into a common challenge when syncing rich text fields like Description between Jira Cloud and Azure DevOps, especially when using Visual Connections. Here’s what you need to know and some practical steps to help:
1. Visual Connection and Description Formatting
Visual Connections (Beta) use default field mappings, which do not automatically convert Jira’s rich text (Atlassian Document Format or HTML) to the Markdown format expected by Azure DevOps.
This often results in lost formatting—paragraphs, line breaks, and lists can be flattened into plain text.
2. Scripted Assignments vs. Visual Mapping
In Visual Connections, the standard field mapping (Description → Description) takes precedence. Any scripted assignment to replica.description (like in Script mode) will be ignored unless you switch to Script mode for that mapping.
So, adding scripts in the background won’t affect Visual Connection behavior.
3. HTML/Markdown Conversion
To preserve formatting, you need to explicitly convert Jira’s Description to Markdown before sending it to Azure DevOps.
This is not handled automatically in Visual Connections. The conversion guide you referenced is for Script mode, where you can use nodeHelper.getHtmlField and then convert HTML to Markdown.
4. Known Limitations
Visual Connections currently do not support custom scripting or advanced field transformations, including HTML-to-Markdown conversion.
This is a known limitation, and for advanced formatting preservation, Script mode is recommended.
5. Recommended Approach
If preserving formatting is critical, consider switching your connection to Script mode. In Script mode, you can use the following approach:
On the Jira side, extract the HTML content of the Description.
Convert the HTML to Markdown.
Assign the Markdown to replica.description.
On the Azure DevOps side, ensure the incoming Markdown is mapped to the Description field.
Thanks for the quick response. I would be interested in knowing how to change from the visual connector to scripting. I am assuming this means that the script has to cover all of the mappings that are now being handled by visual mode. So these will need to be completely replaced by scripting:
The main difference is that when using scripting you can call a specific transformer that we have to format the text accordingly, when using Visual mode, this is not by default use since depending which system you are connecting it could break the formatting.
We have guides on how to create a script sync, Link to Azure Dev ops scripting guide. You can also use the AI Scripting assist we have, where you can prompt to the IA what you need sync and it will generate the code for you.
Thanks for the answers. I have actually designed a new connection that will use script mode instead and I am fairly confident I found everything I need. Since the users I am helping first used visual connector I am attempting to setup a test connector with script mode first.
I am now at a phase where I can temporarily turn off the existing visual connector and turn on my test connector that uses script. The thing I am unsure of though, what will happen to the current entities that are under sync ? I have to be sure of no impact or at least understand the risk that taking this step would bring.
Will appreciate it greatly if someone can chime in and let me know.
@Kevin Any chance you have insights regarding my last comments ? I have a script based connection that I want to test. I want to know what will happen to the current synced tickets that are now connecting via the visual connector ?
If you turn off the existing connection then the tickets that are under sync on that connection will not be updated.
However, Exalate has a functionality built in, where you can create a relationship between two tickets that are already connected and they will continue to be updated under the new connections with the new rules.
There are two options to perform this connection. If you only have a bunch of tickets to connect, you can do it manually where you go to the Exalate console and open the 'Entity Sync status’ and search for one of the tickets and click on ‘Connect’ and you will get a screen to enter the connection you want to use and the remote ID of the ticket.
If there are many tickets you need to connect, there is an option to perform a Bulk Connect operation, where you can provide a CSV with the ‘Local Issue’ and ‘remote issue’ and Exalate will perform the same connect operation but for all the tickets on the CSV file.
