ADO has a very robust and complex RBAC we are using to ensure that users only see what is relevant to them. We want to have ADO continue to be the source of truth for this and import the RBAC to have Port users only be able to see the data they see in ADO and nothing more.

We think this would provide us what we need

workItem ──(areaPath)──► adoAreaPath ──(team)──► adoTeam

This requires two ADO APIs that the integration doesn't currently surface:

Classification Nodes (Areas) — to enumerate every area path in a project:

GET https://dev.azure.com/{org}/{project}/_apis/wit/classificationnodes/Areas?$depth=10&api-version=7.1

Team Field Values — to get the area paths each team owns (with includeChildren):

GET https://dev.azure.com/{org}/{project}/{team}/_apis/work/teamsettings/teamfieldvalues?api-version=7.1

With those, the mapping becomes trivial and exact:

workItem.areaPath = {projectId}::{System.AreaPath} (direct equality)

adoAreaPath.team = populated from teamfieldvalues, expanded for includeChildren

Can we have a kind for an area-path (or classification-node) in the ADO integration, sourced from the Classification Nodes API?

Can the team kind be enriched with each team's configured area paths (from the Team Field Values API)