Synchronization is a process for keeping a structure's issue hierarchy in sync with some other issue properties. Synchronizers run continuously in the background, tracking changes both in Jira and in structures, and when there is a change, make the required updates to one or the other. For example:

• When a Filter synchronizer detects a change in a Jira issue, it will check whether any changes should be done to the structure (add a new issue that now matches the filter JQL, or remove one that no longer does). 
• When a Link synchronizer detects changes to issue links in Jira, it will check for those issues within the structure and adjust their position accordingly. Additionally, if you change the structure (for example, move a child issue under a new parent), it will remove the existing link and create a new one.

Unlike Automations, Synchronizers are adding and removing issues from the structure. If you switch off or remove the synchronizers, the synchronization will stop and all of the issues will remain in the structure, in their last positions. You can edit it further manually.

Potential Conflicts

Since synchronizers run as independent processes, each responsible for synchronizing based on a single rule, they can interact with each other. This may result in some unexpected changes, both within the structure and Jira. This is one of the main reasons we chose to replace them with Automation. Here is one common example:

A user wants to see the issues that are the result of a certain JQL query on the top level of the structure, and all issues linked to them on the level below. The user also wants the top level issues removed from the structure if they no longer pass the JQL. So the user sets up 1) a Filter synchronizer with the Remove option to add (and remove) issues based on the JQL and 2) a Links synchronizer to pull in linked issues. Here is what may happen as a result:

1. Filter synchronizer pulls in the top level issues.
2. Link synchronizer, seeing there are some issues added to the structure, checks if they have any issues linked to them with the selected link type and pulls them in.
3. Filter synchronizer sees there are new issues pulled in and checks if they pass the JQL filter. The child issues do not pass the query of the parents, so they are removed.
4. Link synchronizer sees that the issues were removed. It interprets this action to mean those child issues are no longer needed, so it removes the links between the parents and the children.

As a result, the user would lose a number of links, without realizing it. There are ways to avoid such situations, but this will require a higher level of experience and technical knowledge. You can expect some users will make similar mistakes.

It is also possible for synchrozers to reverse each other's changes, creating an infinite loop. For example, if you have several structures with the same sub-sets of issues, synchronizers in one structure may react to synchronizes in another structure. While there are built-in mechanism to stop this, it may still create some unintended consequences before the safeguards are triggered. 

Fortunately, there is a way to quickly revert such changes if they occur with the synchronizers Undo feature - but it is still desirable to avoid these situations whenever possible.

Synchronizers Undo

To revert changes done by synchronizers, do the following:

1. Go to Jira Administration | Structure | Support.
2. Click View Synchronizer Audit Log.
3. Specify the time period when the synchronizer made the unwanted changes.
4. If you know what structure was affected, specify the structure id. You can see the structure id in the URL when you have the structure open.
5. If you know the exact synchronizer which actions you need to undo, specify the id of this synchronizer. You can find it if you go to the Synchronizers Settings page of a particular structure and hover over any of the links in the Operations column. You'll see the URL with the id in the browser status bar.
6. Click the Show button to see the list of all changes done by the synchronizer. The changes are done in batches, so you'll see the number of "actions" in each batch - you can click Expand to see all the details.
7. Select the ones you'd like to undo and switch to the Undo tab.
8. Review the list of actions which will be reverted and click Undo.

Synchronizers Performance Considerations

When it comes to performance, there are a some things you need to keep in mind:

• Enabled synchronizers run continuously in the background. This means even when a structure is not being used, its synchronizers will continue running and making updates. If you have a large number of structures with synchronizers (a few hundred), their total impact may become noticeable. For this reason, it's important to disable synchronizers for structures which are no longer used. Better yet, delete or archive the structures, since this disables any synchronizers.
• All synchronizers run in a single thread. They make their updates one by one, which means if there is a long queue of updates, there may be quite a long delay between the time you change something in Jira or Structure and the time you see the synchronizers reaction to it. In some extreme cases, it may take several hours and, if the system is slow, the time may grow as more and more updates are added to the queue.

Mixing Automation and Synchronizers

While it is not recommended, it is possible to use Synchronizers together with Automation. If you choose to do this, keep in mind that Automation sees the results of Synchronizers, but not the other way around:

• If you use a Filter Synchronizer to pull issues into a structure, an Extend generator will see these issues and add any issues linked to them. 
• If you use an Insert generator to pull issues into a structure, a Link Synchronizer will not add any child issues to the structure. Synchronizers do not "see" the dynamic content added by Automation.