Tempo Ideas

People join, change role, move teams, become leads, leave. HR already knows all of this. Tempo Teams doesn't, so someone with Tempo Team Administrator goes in and redoes every change by hand, team by team. With a few hundred teams that's a permanent job, it always runs days or weeks behind the real org, and in between approvals go to the wrong lead and the team and capacity reports are off.

Every customer that hits this ends up writing the same thing: a scheduled job that reads joiners, movers, leavers and lead changes from HR or the IdP and pushes them into Tempo Teams through the API. It works, but it's custom code per customer, it breaks when something changes, and it's a strange thing to have to build for what is basically "keep the team list equal to the org chart".

The Cloud v4 API already has everything a sync job needs: update team and lead, end or delete a membership, delete a team, membership search by account. So the ask is not more endpoints. The ask is to make the sync native so nobody has to write it.

Two ways that could look, either one would do.

Tie a team to a Jira or Atlassian group. Whatever the IdP provisions into the group (SCIM, Entra, AD) is the team, and dropping out of the group ends the membership. Lead could be a second group or an attribute on the team. Most orgs already have these groups because they use them for Jira access.

Or an import for teams, leads and memberships with start and end dates, CSV or API, that can be re-run safely and only applies the delta. HR systems can produce that file today without any integration work.

End state: teams in Tempo look like the org chart without anyone maintaining them, approvals land with the right lead the day the change happens, reports are right, and a DC customer migrating to Cloud gets this out of the box instead of porting a custom script.

On DC I'm not asking for new features, I understand where that's going. Just two small things until 2029: document the PUT and DELETE on the team resource that already exist and work, and don't remove the deprecated member delete and deactivate before a documented alternative is there. Customers migrating need their DC sync scripts to keep running until cutover.