# Title: Issue transitions being overwritten by Exalate after rapid status changes (Jira DC to Jira DC)

**URL:** <https://community.exalate.com/t/title-issue-transitions-being-overwritten-by-exalate-after-rapid-status-changes-jira-dc-to-jira-dc/6353>\
**Category:** General Questions\
**Tags:** onpremise-jira, exalate\
**Created:** [April 30, 2025, 3:20pm UTC](https://community.exalate.com/t/title-issue-transitions-being-overwritten-by-exalate-after-rapid-status-changes-jira-dc-to-jira-dc/6353 "2025-04-30T15:20:08Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Javier\_Fernandez\_Fis](https://dub1.discourse-cdn.com/flex018/user_avatar/community.exalate.com/javier_fernandez_fis/32/489_2.png) [@Javier\_Fernandez\_Fis](https://community.exalate.com/u/Javier_Fernandez_Fis)\
**Post date:** [April 30, 2025, 3:20pm UTC](https://community.exalate.com/t/title-issue-transitions-being-overwritten-by-exalate-after-rapid-status-changes-jira-dc-to-jira-dc/6353/1 "2025-04-30T15:20:09Z")

</div>

Hi everyone,

We’re experiencing an issue in our **Jira Data Center to Jira Data Center** synchronization using Exalate, and I’d like to check if anyone has faced something similar or found a workaround.

### **Our setup:**

- We sync issues between a **Jira Software DC** project and a **Jira Service Management DC** project.
- Both projects **share the same workflow** , and we want the statuses to stay in sync.
- We use a technical user (e.g., Usuario\_Sincronizador) to perform Exalate sync actions.

### **The problem:**

- When a user manually performs **several status transitions in quick succession** (e.g., Open → In Progress → Done), everything looks fine **locally**.
- However, **afterwards** Exalate performs **additional, out-of-sequence transitions on the same issue** , using the sync user.
- This results in the issue being moved **backwards or to unintended statuses** , as if Exalate is replaying old states from the queue.

This behavior suggests that **Exalate might be applying outdated sync events** after the issue has already moved forward.

### **Questions:**

- Has anyone seen Exalate apply state transitions **after** the issue has already been manually moved forward?
- Could this be due to **the sync queue processing delayed events** , and if so, how can we prevent this from overriding the current status?
- Would a replica.updated vs issue.updated timestamp check help here, even for status field?

Any advice would be greatly appreciated — especially on how to prevent old sync events from affecting the actual issue’s status.

Thanks in advance!

— Javier Fernández

---

<div class="post-metadata">

**Author:** ![Majid](https://dub1.discourse-cdn.com/flex018/user_avatar/community.exalate.com/majid/32/343_2.png) [@Majid](https://community.exalate.com/u/Majid)\
**Post date:** [May 1, 2025, 10:48am UTC](https://community.exalate.com/t/title-issue-transitions-being-overwritten-by-exalate-after-rapid-status-changes-jira-dc-to-jira-dc/6353/2 "2025-05-01T10:48:19Z")

</div>

Hi,

I think you are running into a conflict resolution problem.

If I have understood the problem correctly, I would point you [here](https://community.exalate.com/t/avoid-updating-issue-with-older-changes-ado-jira-jira-jira-servicenow-jira-zendesk-jira/5229/2). Using the conflict resolution scripts you should be able to “instruct” exalate not to sync changes with older timestamps.

Hopefully this gives you some ideas.

Thanks  
Majid