# Concatenation of Exalate possible? **URL:** \ **Category:** General Questions\ **Tags:** usecase, migrated\_question\ **Created:** [November 4, 2024, 7:58am UTC](https://community.exalate.com/t/concatenation-of-exalate-possible/5339 "2024-11-04T07:58:38Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![xl8bot](https://dub1.discourse-cdn.com/flex018/user_avatar/community.exalate.com/xl8bot/32/324_2.png) [@xl8bot](https://community.exalate.com/u/xl8bot)\ **Post date:** [November 4, 2024, 7:58am UTC](https://community.exalate.com/t/concatenation-of-exalate-possible/5339/1 "2024-11-04T07:58:38Z")
_Originally asked by Antje Stejskal on 07 November 2022 [(original question)](https://oldcommunity.exalate.com/questions/58496299)_ * * * Hi, we setup a Jira system A with Jira Software (A\_JSO) and Jira service management (A\_JSM) and a second instance B with only JSM (B\_JSM). The exalatate connections is between B\_JSM to A\_JSM and from A\_JSM to A\_JSO. I created an issue that was subsequently crerated on A\_JSM and B\_JSM. Then I made two modifications of the description - A\_JSO and B\_JSM . A\_JSO endet up displaying the modification I made on B\_JSM, and A\_JSM and B\_JSM display the modifications made on A\_JSO. So is this not a supported scenario? Or is there a configuration leading to all 3 versions of the issue displaying the sam content? * * * ---
**Author:** ![xl8bot](https://dub1.discourse-cdn.com/flex018/user_avatar/community.exalate.com/xl8bot/32/324_2.png) [@xl8bot](https://community.exalate.com/u/xl8bot)\ **Post date:** [November 4, 2024, 7:58am UTC](https://community.exalate.com/t/concatenation-of-exalate-possible/5339/2 "2024-11-04T07:58:39Z")
_Answer by Ezequiel Consorti on 08 November 2022_ Hi Antje, Thanks for reaching out to us with your question! While I understand you would expect to have the same description in all 3 issues, please note that the reason why you ended up with a different description in one of the issues is because the updates were done almost simultaneously. In your scenario the Issue description was modified first in B\_JSM (Descriptio .A) and then almost simultaneously in A\_JSO (Description.B) 1. **D.A** gets synced from **B\_JSM** to **A\_JSM** while **D.B** is posted in **A\_JSO** (At this point you have **B\_JSM** w/ **D.A** (original) **A\_JSM** w/ **D.A** (sync1) **A\_JSO** w/ D.B (original)) 2. **A\_JSM** updates **A\_JSO** sharing **D.A** while at the same time **A\_JSO** updates **A\_JSM** sharing **D.B** ( **B\_JSM** w/ **D.A** (original) **A\_JSM** w/ **D.B** (sync2) **A\_JSO** w/ D.B (sync1)) 3. **A\_JSM** was updated a second time and syncs the update with **B\_JSM** ( **B\_JSM** w/ **D.B** (sync1) **A\_JSM** w/ **D.B** (sync2) **A\_JSO** w/ **D.B** (sync1)) A way to avoid this is to implement a rule in your scripts that checks the timestamp on each update and only syncs the description coming from the remote side if it is older than the current description in the destination. In the following community post with a similar scenario [Avoid updating issue with older changes ADO \<\> Jira, Jira \<\> Jira, ServiceNow \<\> Jira](https://oldcommunity.exalate.com/questions/42839472/avoid-updating-issue-with-older-changes-ado-jira-jira-jira-servicenow-jira-zendesk-jira)_(old community)_, you can find a video explaining how this script works and a detailed explanation on the whole logic behind it. While I will be sharing the scripts directly in this post, I highly encourage you to review the shared one to have a better understanding on the subject. ```auto // Outgoing Sync Rules // Avoid updating issue with older changes Jira <> Jira replica.changeHistory = issue.changeHistory ``` ```auto // Incoming Sync Rules // Avoid updating issue with older changes Jira <> Jira def fieldToLastUpdateDateFn = { exalateUserKey -> { history -> history .sort { c -> c.created.time } .reverse() .findAll { c -> c.author.key != exalateUserKey } .inject([:]) { result, c -> c.changeItems.inject(result) { r, i -> String k = i.field if (r[k] == null) { r[k] = c.created } r } } }} if (firstSync) { issue.summary = replica.summary issue.description = replica.description } else { def HOUR = 1000 * 60 * 60 def THREE_HOURS = 3 * HOUR def remoteFieldToLastUpdateDate = fieldToLastUpdateDateFn("exalate")(replica.changeHistory) remoteFieldToLastUpdateDate = remoteFieldToLastUpdateDate.inject([:]) { r, k, v -> r[k] = new Date((v + THREE_HOURS) as Long) r } def localFieldToLastUpdateDate = fieldToLastUpdateDateFn("exalate")(issue.changeHistory) if (remoteFieldToLastUpdateDate."description" > localFieldToLastUpdateDate."description") { issue.description = replica.description } if (remoteFieldToLastUpdateDate."summary" > localFieldToLastUpdateDate."summary") { issue.summary = replica.summary } if (remoteFieldToLastUpdateDate."Severity" > localFieldToLastUpdateDate."Severity") { issue.Severity = replica.Severity } } ``` By implementing this script in your scenario **A\_JSO** shouldn’t be updated with the description coming from **B\_JSM** as **D.B** is older than **D.A** leaving all 3 issues with the same description **(D.B)**. Please note that the shared script implements the timestamp rule for description and summary, you can include or exclude more fields from this rule by adding additional if() or removing an existing one. I hope you find this information useful! Regards, Ezequiel * * *