Cross-profile Relations Sync

Sometimes it is impossible to map several teams in one integration profile because of very different workflows. If Features of Engineering team have drastically different set of fields and validation rules and automations than Features of Accounting or Marketing departments (aka any other work item type mapped by hierarchy to an ATP Feature) it’s easier to set up separate integration profiles and manage those integrations separately. At the same time, as a portfolio owner you need to see how those work items affect company strategy, OKRs or roadmap. Or, for example, sometimes you need to track what work items arerelated to a customer idea or request. And then you need relations from Jira or Azure DevOps sync across multiple profiles.

This is a quick solution to validate cross-profile relations functionality. In this implementation, one profile becomes a master profile for relations mappings, all relations between cards synced with master profile to cards from other selected profiles will be synced. But relations between other profiles’ cards will not sync in this version. It supports use case when work items, shared by different profiles, connect to an Initiative shared by the other profile.

Instructions/ Steps:

1. Functionality is not widely available till Q4 2024 and can be enabled by direct request to Product Manager – Nadia.bulynia@ibm.com.

2. When the feature is enabled, integration administrator can choose what profiles will be syncing their relations with main profile. List of profiles is managed from the ‘main’ profile whose relations mapping will be used for cross-profile relations sync (in case relations are mapped differently from one profile to another)

3. Other profiles selected in the list will show a yellow reminder explaining why some relation links types might be different than current profile mapping and a name of the profile that overrules those mappings.

4. Profiles selected in the list still will not share relation between their work items, only relations to items from the parent profile.

For example,  Profile A:

Types: Targetprocess Epics <> Epic

Relations: Relation <> Successor / Predecessor

Profile B:

Types: Targetprocess User Story <> Story

Targetprocess Epics <> Epic

Relations: Blocker <> Successor / Predecessor, Tested By/Tests

Profile C

Types: Targetprocess Objective <> Initiative

Relations: Link <> Child/Parent, Successor / Predecessor

5. In Azure DevOps we see hierarchy:

6. Hierarchy in Targetprocess