Best practice for SF Case Merge when the synced case is not the master case

General Questions
1

Hi all,

We have a Salesforce–Jira sync in place using Exalate and would appreciate your recommendation for handling a specific scenario.

  • SF Case A is synced with Jira Ticket A.
  • Comments are synchronized in both directions.
  • SF user merges duplicate cases (SF Case A and B)

In most cases, the synced case (Case A) remains as the master case after a merge. However, there are situations where we need to keep Case B as the master case and merge Case A into it.

When this happens:

  • SF Case A is merged into Case B.
  • Comments from Case A are no longer available on the original Case A record.
  • Exalate interprets this change and removes the synchronized comments from Jira as well.
  • As a result, historical information on the Jira side is lost.

Question

What would you recommend as the best practice for handling this scenario?

At the moment, we are experimenting with terminating the synchronization as soon as Salesforce marks the case as merged, in order to preserve the comments and history in Jira.

Has anyone dealt with a similar Salesforce merge scenario? Is there a recommended pattern to:

  • preserve Jira comments/history,
  • avoid comment deletion,
  • and still handle Salesforce merges correctly?

Any advice would be greatly appreciated.

Thanks,
Balkan

2

This is a great question and a common challenge when syncing Salesforce Cases with Jira issues, especially around the merge scenario where the synced case is not the master. Here’s a summary of best practices and considerations based on Exalate’s documentation:

  • When a Salesforce Case is merged into another (and is not the master), Salesforce marks the original case as merged and removes its comments and history. If Exalate continues to sync after this, it interprets the removal as deletions and mirrors those deletions in Jira, leading to loss of historical data on the Jira side.
  • To prevent this, your current approach—terminating the sync as soon as Salesforce marks the case as merged—is recommended. This ensures that Jira retains the comments and history from the original case, as Exalate will no longer process deletions from the merged (now non-master) case.
  • You can implement this by detecting the merge status in your outgoing sync script. When a case is marked as merged (for example, by checking the IsMerged field or a similar indicator), you can trigger an Unexalate or stop synchronization for that case. This prevents further updates, including deletions, from being sent to Jira.
  • If you want to maintain a link between the new master case (Case B) and the Jira issue, you could consider updating the sync to point to the new master, but this requires careful handling to avoid data inconsistencies.

For more details and script examples on handling merges and terminating syncs, check out the Exalate documentation on Unexalate for Salesforce and handling record deletions and merges.

In summary: terminating the sync when a case is merged (and is not the master) is the best way to preserve Jira history and avoid unwanted deletions. If you need to handle more complex merge scenarios, consider custom scripting to manage the transition between cases.

Hope this helps clarify the best practice!

3

Hi @balptimur,

Welcome to the community!

There are a couple of approaches you could take here:

  • If you don’t need to keep the Jira issue synchronized after the Salesforce Case is merged, you could terminate the synchronization when the merge is done. This would preserve the existing Jira history. Manual Unexalate or via unExalateAfterProcessing()
  • If you need to keep the Jira issue under sync, I would recommend making the comment synchronization append only by processing only newly added comments:
issue.comments += replica.addedComments

This way, new comments will continue to synchronize, while comments removed from Salesforce as a result of the merge won’t be deleted from Jira.

But comment edits or intentional deletions from Salesforce would no longer be reflected in Jira.