How linking between Issues in Jira and Workitems in ADO are held in On-Premise Synchronizer.

How linking is stored

When creating a profile you choose which field is used to store pairing workitem-issue:

Open

In this example on the Jira side, we chose customfield with Id 10126 which will be shown as TFSId in Jira UI, while on Azure DevOps side we created a process called Jira and created a field called Jira as well which is shown as Jira.Jira.

Example:

Issue Scrum-50 in Jira is linked with Workitem 747 in Azure DevOps. In Jira, in field TFSId we see a number stored:”747”

Open

If we go to the workitem with Id 747 we see that in field Jira (Which we have given label Jira issue Id) is stored value “SCRUM-50”.

How it can be used

1. Unlinking mapping between issues.

If you would like to at any point unlink tickets and create a new counterpart, just delete the content of the field and Synchronizer will assume the issue/workitem is not synchronized and create a new counterpart.

2. Issue/workitem deletion.

When you plan on deleting issues or worktiems remember to clean up the custom field content in paired workitem/issue to avoid recreation

3. System migration

The pairing between issues and workitems are stored in that customfield so if you plan on migrating to or from Cloud and would wish to keep the sync ongoing, remember to preserve the contents of this field.

F.A.Q.

1. Why not use internal Synchronizer DB?

We chose the means of using customfield in order to make TFS4JIRA Synchronizer resistant to downtime and data loss. If you lose machine running TFS4JIRA synchronizer the linking is not lost, but preserve in workitems/issues

2. Can I restrict who can edit this customfield?

Unfortunately, at this moment there is no option in Jira to limit who can or cannot edit the field.