Applies to:
TFS4JIRA Cloud and Self-hosted
In TFS4Jira, when you map fields in the profile configuration, you are able to map multiple fields on one side to one field on the other, like in this example:
However, there is a specific logic behind the synchronization of the values when fields are mapped this way. In the example above, Azure’s “Description” and “Acceptance Criteria” are mapped to “Description” in Jira. We use one-way synchronization from Azure → Jira, and Azure’s “Description” is selected as the primary field. With this setup, an Azure Work Item with a Description field will have it’s value synchronized with the Description in Jira. However, if the work item uses the Acceptance Criteria field, it’s value will not be migrated as Jira’s Description.
This is because only the “Primary” field in a field multi-mapping has read/write permissions, while all others only have write. The example above shows a one way synchronization. With bi-directional synchronization enabled, the mapping would look like this:
Jira Azure
Description ↔︎ Description (Primary)
→ Acceptance Criteria
In the above setup, synchronization from Azure → Jira would work the same as one-way synchronization. However, while synchronizing from Jira → Azure, the synchronizer first checks if the Description field is available for the target work item type. If not, it will look for the Acceptance Criteria field and put the Jira Description value there.
Our recommendations
The most reliable solution for synchronization is to always have a unique link for each field instead of using the multi-mapping feature. However, if you cannot add new fields in either Jira or Azure DevOps, we recommend setting up a separate profile to synchronize that Issue/Work Item type. For example, Acceptance Criteria is usually specific to “Bug” work item type in Azure DevOps. You can copy your existing synchronization profile and use it for Bug synchronization only. Therefore, you will be able to map Jira’s Description only to Azure’s Acceptance Criteria.