Step 3: Create a synchronization link

In the Synchronizer Configuration wizard, click Create link.

Select an endpoint from the endpoints you defined, and then follow the steps described below. The order of the steps may vary, depending on the type of entity synchronized over this link (defects, requirements, or releases).

Define link properties

Select the type of entity synchronized over this link (defects, requirements, or releases).
Define a name for your link, and an optional description.
If you work with multiple workspaces, select the workspace you want to synchronize with ALM or Jira.

If you do not see your workspace in the drop-down list, make sure you are defined as a Synchronizer Admin in this workspace. For details, see Define a Synchronizer Admin user.
Click Check Connectivity and Continue.

Map requirement types (backlog links)

ALM:

Specify the ALM requirement types that match user stories, features, and epics, according to the hierarchy that you defined in advance in ALM. For details on setting up this hierarchy, see In ALM, prepare requirement types to match ALM Octane's (requirement synchronization).

You can map multiple ALM requirement types to user stories and features. Specify one type as the default for ALM. This requirement type is used when synchronizing new ALM Octane items with ALM.

Jira:

Map Jira epics and stories to ALM Octane features and stories. Note that ALM Octane has three levels of hierarchy while Jira has two levels, so ALM Octane epics are not mapped.

You can then define which endpoint controls the synchronized entities.

Note: Only mapped requirement types are synchronized.

Set the rules that define which endpoint controls the synchronized entities

Select where you plan to manage your releases, defects, and different types of backlog items.

Caution: ALM Octane does not support custom release fields.

For releases, Synchronized data includes:

Releases: Names, start and end dates, descriptions, and attachments.
Sprints/cycles: Names, start and end dates.

If you have custom release fields that are mandatory in ALM or Jira, synchronize release data only from ALM or Jira to ALM Octane, and not from ALM Octane to ALM or Jira.

Select one of the following:

Option	Description
ALM Octane	Select this option to create defects, backlog items, or releases in ALM Octane only. During synchronization, corresponding entities are created automatically on ALM or Jira. Updates made to existing entities in either endpoint are synchronized with the other endpoint. For backlog links: This option means that you manage the entity's hierarchy (epic > feature > user story) in ALM Octane. Changes that you make to the structure of your backlog tree in ALM or Jira will be reverted by the synchronization.
ALM/Jira	Select this option to create defects, backlog items, or releases in ALM or Jira only. During synchronization, corresponding entities are created automatically on ALM Octane. Updates made to existing entities in either endpoint are synchronized with the other endpoint. For backlog links: This option means that you manage the structure of your backlog tree in ALM or Jira. Changes that you make to the entity's hierarchy (epic > feature > user story) in ALM Octane will be reverted by the synchronization.
Both ALM Octane and ALM/Jira	Select this option to create and update defects, backlog items, or releases in both ALM Octane and ALM or Jira, for a full range of planning and testing functionality. Changes made in either endpoint are synchronized with the other endpoint. Note: Two options are available for managing entities in both endpoints. One sets ALM Octane as the dominant side, in case of conflicts, and the other sets ALM or Jira as the dominant side. For backlog links: This option means that you can change the entity's hierarchy (epic > feature > user story) in either endpoint. Changes that you make to the structure of your backlog tree are synchronized in the other endpoint. In case of conflict, the structure of the dominant side is used.

Option

Description

ALM Octane

Select this option to create defects, backlog items, or releases in ALM Octane only.
During synchronization, corresponding entities are created automatically on ALM or Jira.
Updates made to existing entities in either endpoint are synchronized with the other endpoint.

For backlog links: This option means that you manage the entity's hierarchy (epic > feature > user story) in ALM Octane. Changes that you make to the structure of your backlog tree in ALM or Jira will be reverted by the synchronization.

ALM/Jira

Select this option to create defects, backlog items, or releases in ALM or Jira only.
During synchronization, corresponding entities are created automatically on ALM Octane.
Updates made to existing entities in either endpoint are synchronized with the other endpoint.

For backlog links: This option means that you manage the structure of your backlog tree in ALM or Jira. Changes that you make to the entity's hierarchy (epic > feature > user story) in ALM Octane will be reverted by the synchronization.

Both ALM Octane and ALM/Jira

Select this option to create and update defects, backlog items, or releases in both ALM Octane and ALM or Jira, for a full range of planning and testing functionality. Changes made in either endpoint are synchronized with the other endpoint.

Note: Two options are available for managing entities in both endpoints. One sets ALM Octane as the dominant side, in case of conflicts, and the other sets ALM or Jira as the dominant side.

For backlog links: This option means that you can change the entity's hierarchy (epic > feature > user story) in either endpoint. Changes that you make to the structure of your backlog tree are synchronized in the other endpoint. In case of conflict, the structure of the dominant side is used.

When you synchronize a release, all related ALM Octane sprints are synchronized with ALM cycles or Jira sprints.

For a release link, select the endpoint to use as the dominant side for sprint and cycle synchronization, in case of conflicts.
When you synchronize with Jira, you can use the shared space parameter ONLY_SHOW_ACTIVE_RELEASES to hide deactivated releases (in ALM Octane) and archived versions (in Jira) from value mapping. If set to true, these releases and versions will be hidden and you will not need to map them to pass the integrity check.
In an ALM Octane shared space, the remote project (ALM/Jira) is mapped to an ALM Octane workspace. However, you cannot update a release in the workspace context. You therefore cannot synchronize changes to releases (create/update/delete) from ALM/Jira to ALM Octane, but only from ALM Octane to the remote context. In this case the link must be unidirectional, from ALM Octane > ALM/Jira.
If comments are added for the same entity both in ALM Octane and ALM/Jira between consecutive synchronizations, only the comments from the dominant side are synchronized. The comments from the non-dominant side are removed.

You can view the rules in more detail after you create the synchronization link, and adjust them if necessary, in the link configuration Rules tab.

Optional: Select favorites (backlog and defect links)

You can limit the synchronization to a subset of your ALM, Jira. or ALM Octane database by using ALM Octane and ALM or Jira favorites.

Tip: For backlog links, you can also use an alternate root folder for a similar purpose. If you define both favorites and an alternate root folder, the alternate root folder is considered first.

Select favorites to use as filters for new items when synchronizing between endpoints. For details, see Define the synchronization scope.

No favorites are defined by default. This means that all records in the ALM Octane workspace and the ALM or Jira project are synchronized.

Optional (ALM only): Define an alternate root folder (backlog and release links)

You can limit the synchronization to a subset of your ALM database by selecting an alternate ALM root folder.

Select Use an alternate root folder and enter the path to a sub-folder in your ALM project's Requirements or Releases folder.

The path must replicate the exact hierarchy in ALM starting with the Requirements or Releases folder, according to the ALM locale. For example: Requirements\MyProject.

Note: For a backlog link, if you define both favorites and an alternate root folder, the alternate root folder is considered first.

Caution:

Make sure the folder that you enter already exists in your ALM folder structure.
Specifying an alternate root folder for synchronization can cause unexpected behavior.

If you reorganize the Requirements or Releases module in ALM after having run a synchronization task, carefully move the records while retaining the same hierarchy to retain the synchronization. Do not delete records and create new ones in the new location, as ALM Octane Synchronizer recognizes records according to their ALM ID.

When you move records, make sure to retain the same hierarchy as is defined for the link in ALM Octane Synchronizer.
If you move a record out of the alternate root folder in ALM, this record is no longer synchronized with ALM Octane.

However, if you move a release out of the alternate root folder, the release is no longer synchronized, but its cycles are still synchronized.
You can change the path to the alternate root folder until you run the first successful synchronization for the link.

Optional: Specify how to handle requirements whose hierarchy does not match the backlog tree (backlog links)

Your ALM or Jira requirement synchronization hierarchy might not fully match the ALM Octane epic > feature > user story hierarchy.

For example, if a requirement of a type mapped to user stories is a child of a requirement whose type is mapped to epics. A requirement of a type mapped to features may be a child of a requirement not mapped for synchronization at all.

For requirement types mapped to epics or user stories, you can instruct Synchronizer to ignore a requirement's hierarchy when it does not match. Such requirements are then synchronized directly to the root of the ALM Octane backlog tree: Select Synchronize epics and user stories to the Backlog root.

Tip: We recommend that you select this option.

This option is not relevant for features. Features whose parents are not epics will still fail to synchronize.

Specify how to handle existing or past releases (release links)

Select Synchronize past releases... if you want to synchronize releases whose end date is in the past. By default, ALM Octane Synchronizer synchronizes only current releases.

If you select this option, enter a date to prevent synchronizing old releases that you do not need. This date cannot be in the future.
Select Map pairs of new releases and sprints/cycles with identical names if you want to use data from the dominant endpoint for all fields of the identically named release or sprint/cycle in the other endpoint.

In ALM synchronization, if you do not select this option the pairs of identically named release or sprints/cycles are not synchronized at all. A "duplicate entities" error is generated in the run report.

Note: When mapping, ALM Octane Synchronizer checks only the releases that are included in the synchronized time frame. Releases or sprints/cycles with identical names are not mapped if they are in a past release (or a release whose end date is older than the one you specified for synchronization).

If you are working in a shared space (see Manage spaces (for space admins)), when you update a shared release in a remote endpoint this is not synchronized to ALM Octane. Releases created in a remote endpoint are not shared in ALM Octane.

Next Steps

When you are finished creating your link, do the following:

Caution: If you create a link and then delete it, and you then create it again using the same conditions, any defects or requirements that were already synched will be duplicated (in either direction of synchronization).