Group sync
Map your IdP groups to gittan teams — because maintaining two sources of truth is how access gets stale.
Why group sync exists
Your IdP already knows who belongs to which team. Duplicating that in gittan means two lists to maintain and two places where they can drift. Group sync bridges the gap: your IdP groups map to gittan teams, so when someone joins or leaves in the IdP, their git access follows.
How it works
An admin triggers sync via Admin → Sync groups or the API
(POST /orgs/:orgId/sync-groups). gittan
reads the group claims from your OIDC provider and matches them against existing
teams.
Groups that match an existing team are synced — user memberships update to reflect the IdP. Groups that don't match are listed as unmapped. You decide whether to create a team for them or ignore them.
What syncs
| IdP change | gittan result |
|---|---|
| User added to a mapped group | User joins the matching team on next sync |
| User removed from a mapped group | User leaves the matching team on next sync |
| New group, no matching team | Listed as unmapped — create a team manually if needed |
Why sync is explicit, not automatic
Sync is triggered by an admin, not on every login. This is intentional — automatic login-time sync can lock people out during IdP misconfigurations. You want a human in the loop when membership changes happen at scale.
Why we don't auto-create teams
gittan won't create teams from IdP groups automatically. IdP group structures often include groups that don't map cleanly to code ownership — "all-staff", "office-stockholm", "contractors". Auto-creating would fill your org with teams nobody asked for. Instead, you create the teams you need and map them.
Set up SSO first so your IdP sends group claims. Then use sync to map those groups to teams.