The Difference Between One-way Sync and Two-way Sync

Distinguish between one-way and two-way synchronization

A two-way sync treats all spaces (projects) in a group as equals, meaning that any new version added to one space is automatically synchronized across all other spaces in the group. This setup is ideal for teams like Development, Marketing, and QA, who work on the same software releases and need to stay aligned.

On the other hand, a one-way sync is more directed, with versions being synced from a source or primary space to one or more target spaces. In this case, new versions added to a source space are synced to the target spaces, but not the other way around. However, updates to existing synced versions will propagate across all spaces, regardless of where the change is made. This allows for more controlled and selective synchronization, suitable for more complex space structures.

Two-way Sync

With a two-way sync group, you can sync versions across a group of Jira spaces.

In a two-way sync, all spaces are considered equal. New versions, no matter in which space, are synchronized within the group.

Use Case: If you have e.g. three different teams (Dev, Marketing, QA) which work on the software product and contribute to the same releases, you create a two-way sync group that contains all spaces.

If you add a new version to any space it gets automatically synced to the other two spaces in the group.

We usually recommend the two-way sync because it covers most of the use cases.

• Learn more about “How to Sync Versions Two-Way”

One-way Sync

In contrast, a one-way sync is a directed sync from a source/primary space to one or more target spaces. With the one-way sync, you can build an advanced sync group, with several source/primary and target spaces.

If you add new versions to a source/master space, it will be synced to its target spaces. If you add a new version to a target space, it won’t be synced with any other space.

“One-way” refers to how new versions are being synced among the spaces in your group. That means, if you update an existing, synced version (e.g. change its name), it doesn’t matter in which space you update the synced version - it will update the versions in all other spaces as well.

It is possible to have groups with several sources or several target spaces, as you can see in this example.

Use case: If you have two development teams working on different spaces and a QA team supporting both development teams, you can create a sync group with two source spaces (Dev1 and Dev2) and one target space (QA).

If you add a new version to Dev1 it gets automatically synced to QA, but not to Dev2. The same applies to space Dev2.

• Learn more about “How to Sync Versions One-Way”