I've gone through the KB articles How to update a local custom field with the remote issue key. However this is done during the synchronisation process and works only for the 1st sync (new issues).  This does not work for issues already synced even though I did a bulk exalate.


If I were to unexalate followed by connect, the remote issue key field will be updated but this will create duplicates in attachments and comments, hence I would not choose this option.

Is there another way to retrieve the remote issue key for existing / old issues? Eg. ability to fetch the remote issue key preferably in JQL, or using REST API or through groovy script (e.g. ScriptRuner) ?

We need to display the remote issue key in JQL search results for export and reporting purposes.

I hope there is a workaround for this, as it will be very useful.


    CommentAdd your comment...

    1 answer


      Hi Hi don't know if I understood your question correctly, and I'm also a user but in general you can assign the remote issue key as follows.

      Outgoing on the remote side (but this is in the standard script if not changed) 

      replica.key               = issue.key

      Incoming you can just do this

      issue."YourCustomField" = replica.key (for simple custom field → String) 

      there also is the option to do 

      issue.customFields."YourCustomField" = replica.key (but doesn't sound like you need that) 

      This will be executed with each sync but only be applied if there is a change if I understand correctly 

      If you are then using the custom field to do something else it shouldn't be affected since there is no change 



      1. Marianne Lee

        Hi Max,

        Thanks for your suggestion, and you're right in that the issue.customFields."YourCustomField" will be updated with replica.key with each sync, i.e. with each change.

        This solves part of the problem.  The other part getting the remote issue keys for completed/old issues which no longer get new changes.  I do not want to initiate an update (add a comment, etc.) as that would modify the issue update date, which then would not be reflected correctly.

        Any ideas on how to tackle that?



      2. Francis Martens (iDalko)

        Hi Marianne Lee, Maximillian Thomas Nadolny 

        You are both on the right track.

        The bulk exalate will only message the twins whenever the replica is changed.
        If the replica is the same since previous message, nothing will happen.

        By adding something like

        replica.foo = new Date()

        To the outgoing sync, a message will also be sent.

        Knowing this you can

        • Adapt the outgoing sync
        • Perform a bulk exalate on all previously synced issues (ie by using a JQL which covers everything)
        • Remove the foo statement from the outgoing sync

        Also note that if you have the connection JiraA to JIraB, and you want to have the JiraB key on the JiraA issues, you will need to adapt the outgoing sync on JiraB and run the bulk exalate on JiraB.

        Give it a try and let us know

      3. Kiet Ngo

        Hi Francis Martens (iDalko)

        Thanks for your response.

        I have the same issue with Marianne Lee , was following this thread. I want to perform bulk exalate changes but don't know how to get the csv file input here. I have few thousands of issues. What is the best way to do it? 

      4. Francis Martens (iDalko)

        The screenshot you provided is of the 'Bulk Connect', which is a different feature than the Bulk Exalate

        Check Bulk Exalate for more details

      CommentAdd your comment...