Azure DevOps Integration: How to sync Area Path and Iteration Path

Area Path in Microsoft Azure DevOps supports teamwork and group work items based on a product or business unit. In Azure DevOps, you can even create a tree-hierarchy of area paths to organize teams into hierarchy.

The current integration does not support team hierarchy, which means you will need to decide which level of Area Path will represent Teams and follow this logic across all projects and teams integrated with Targetprocess.

Both Area and Iteration Path can be mapped only as fields. Mapping to an object – entity like Team, Agile Release Train or Team Iteration, and two-way synchronization of these objects is not possible, considering that Area Paths and Iteration Paths are not regular objects in Azure DevOps, and their updates do not fire webhook events.

Such mapping would be a future integration improvement that is not yet planned on the roadmap.  

Logically, Area Path means Departments as Agile Release Trains and Teams and Iteration Path means Releases and Iterations. For example, Area Path: Azure DevOps Project/Team; Iteration Path: Azure DevOps Project/Release/Iteration.

Different teams and projects in Azure DevOps can utilize those levels differently to track their Iterations and Releases plans.  To map Releases and Iterations to Targetprocess via single integration profile, it is crucial to agree on mappings and patterns to what Targetprocess object which level of the Path corresponds.

Recommended mapping

Basic Use Case

In a basic use case, so-called three-level area path, we assume that connected Azure DevOps Projects (Area Path and Iteration Path root) map to team projects in Targetprocess. Second level of Area Path maps by name to Targetprocess ART and level 3 to Targetprocess TeamSuggested mappings work by name, therefore Targetprocess Projects, ARTs and Teams names must be the same as Azure DevOps Path’s levels.

Area Path Root (ADO Project) – Targetprocess Project
Area Path Level 1 – Agile Release Train (aka ART)
Area Path Level 2 – Targetprocess Team (Team belongs to some ART)

Iteration Path correspondingly has three following levels parsed:

Iteration Path Root (ADO Project)– Targetprocess Project
Iteration Path Level 2 – Targetprocess Program Increment
Iteration Path Level 3 – Targetprocess Team Iteration

In Targetprocess domain model Releases and Teams are related to ARTs, and Team Iterations on Teams. For integration mapping it means, that Area and Iteration Paths mappings are very connected. Just one level change in Area Path can impact multiple fields in Targetprocess. And vice versa, different Targetprocess fields can affect each other and as follows for an Area or Iteration Path in Azure DevOps.

Considering that Targetprocess syncs with multiple Azure DevOps projects, we need to define the Iteration Path root level explicitly for all Team Iterations. Therefore we suggest to have an Azure DevOps Project field in Targetprocess Team, which will define where in Azure DevOps Iterations for that Team must be created.

That is how it looks in production setup:

See mappings examples in our GitHub library for Azure DevOps basic user case mappings

We also suggest using additional Automation Rules in Targetprocess to automate import of all new Team Iterations and Released to Azure DevOps Paths.  See mappings examples in our library on GitHub.