How to Sync GitLab Groups With Google Groups
SyncMyGroup team · October 28, 2026
If your company runs on Google Workspace and your code lives in GitLab, you've probably got a version of this: backend@company.com in Google, a backend group in GitLab, and a manual step in onboarding that says "add them to the right GitLab groups." That step is where access drifts. New hires wait for repository access, and leavers keep it until someone remembers.
GitLab has several built-in ways to automate group membership. Each comes with specific tier, offering and identity provider requirements. This post goes through them, where Google Workspace fits, and how to sync Google Groups to GitLab groups when the native options don't fit.
How GitLab group membership works
A few GitLab concepts shape any sync:
- Groups and subgroups. GitLab groups can contain subgroups and projects. Members of a parent group are inherited members of its subgroups and projects.
- Roles. Each membership has a role. GitLab's access levels are Guest (10), Planner (15), Reporter (20), Developer (30), Maintainer (40) and Owner (50), with Owner only valid on groups. Custom roles are an Ultimate feature.
- Top-level group on GitLab.com. On GitLab.com, your organisation is a top-level group. Everything else is a subgroup inside it.
Inheritance is the important one. Adding someone to company/engineering gives them access to everything under it. Decide which level each Google Group maps to with that in mind.
The native options
SAML Group Sync
GitLab's SAML Group Sync maps groups from your identity provider's SAML response to GitLab groups. Per GitLab's documentation (2026):
- Tier: Premium or Ultimate, on GitLab.com, Self-Managed and Dedicated.
- When it runs: membership is evaluated each time a user signs in with SAML. IdP group members are added to the GitLab group on their next SAML sign-in.
- Removals: after a sync, users who aren't members of a mapped SAML group are removed from the GitLab group. On GitLab.com, users in the top-level group get the default membership role instead of being removed.
- Roles: each SAML group link maps one IdP group to one access level. If several links point at the same GitLab group, the user gets the highest role.
- Groups aren't created. You create the GitLab group first, then add the mapping. Group names are case-sensitive and must match the SAML response exactly.
Google Workspace can send group membership in a SAML response. Google's admin help says the group membership attribute is available for custom SAML apps, with up to 75 group names per response. When a user is in a subgroup of a configured group, both the subgroup and the parent are sent.
So with Google Workspace as your SAML IdP and GitLab Premium, SAML Group Sync is a workable option. Its limits:
- Changes wait for sign-in. A new hire is added to
backendwhen they next sign in through SAML. A leaver's membership changes when they next sign in — and if their Google account is suspended, they won't. - Premium is required. On GitLab Free there's no SAML Group Sync.
- The 75-group limit matters if you send many groups per user.
SCIM
On GitLab.com, SCIM provisioning synchronises group membership between GitLab and an identity provider. GitLab's documentation (2026) lists it as Premium and Ultimate on GitLab.com, and names Okta and Microsoft Entra ID as the supported identity providers; others may work but aren't tested or supported. It also notes that SCIM group provisioning isn't supported, so IdP groups aren't created in GitLab through SCIM.
Google Workspace isn't on that list. If Google is your directory, SCIM isn't the route.
LDAP group sync
On GitLab Self-Managed, LDAP group sync (Premium and Ultimate) links GitLab groups to LDAP groups. By default it runs every hour, on the hour. It isn't available on GitLab.com. If you're self-managed and already have an LDAP directory in front of Google, it's an option; if not, it adds infrastructure.
Summary
| Option | Tier (2026) | Offering | Works with Google Workspace | Updates when |
|---|---|---|---|---|
| SAML Group Sync | Premium, Ultimate | .com, Self-Managed, Dedicated | Yes, via group attribute | User signs in |
| SCIM | Premium, Ultimate | GitLab.com | Not a supported IdP | IdP pushes |
| LDAP group sync | Premium, Ultimate | Self-Managed | Only via an LDAP directory | Hourly by default |
| Manual | Any | Any | n/a | When someone remembers |
Where a sync tool fits
A group sync tool takes a different approach: it reads the Google Group's members through Google's API and adds or removes members in the GitLab group through GitLab's API. That means:
- Changes don't wait for the user to sign in. A leaver removed from
backend@is removed from the GitLab group when the sync runs, whether or not they ever sign in again. - No SAML or SCIM dependency. It doesn't require a SAML integration between Google and GitLab, and it doesn't depend on SCIM IdP support.
- Nested Google Groups are flattened. If
engineering@containsbackend@andfrontend@, the people inside are what reach GitLab. See how flattening works. - You can see the change before it happens. A preview shows who will be added and removed.
SyncMyGroup syncs GitLab teams and groups with Google Groups, and with Slack, GitHub, Jira, Linear and the other tools it connects. It creates groups in the destination when they don't exist, adds and removes members to match the source, and supports filters, exclusions and permanent users.
One honest caveat: everything above is about membership. If you need different GitLab roles for different people in the same group — Developer for most, Maintainer for leads — check how roles are handled in the docs or ask us before you rely on it. A common pattern that avoids the question is to map role tiers to separate Google Groups and separate GitLab subgroups.
Setting it up
1. Plan the mapping
Sketch it before connecting anything. Keep inheritance in mind.
| Google Group | GitLab group | Effect |
|---|---|---|
engineering@ | company/engineering | Access to every project under engineering |
backend@ | company/engineering/backend | Backend projects only |
frontend@ | company/engineering/frontend | Frontend projects only |
contractors-eng@ | company/engineering/contractors | Only the projects shared with this group |
Avoid mapping a broad group high in the tree "for convenience." Inheritance makes over-granting easy.
2. Check accounts and emails
This is the step that catches most GitLab syncs.
- GitLab.com accounts are often personal. Many developers sign in to GitLab.com with an account they've had for years, with a personal primary email. A sync that matches by work email won't find them. Decide your policy: require work-email accounts, or make sure each person's work email is on their GitLab account.
- Self-managed instances usually have accounts tied to your domain, so this is less of an issue.
- Service accounts and bots have no Google identity. Pin them as permanent users or exclude them.
3. Connect Google Workspace and GitLab
In SyncMyGroup, add both integrations. The GitLab connection needs an account with permission to manage members of the groups you're syncing.
4. Create a sync team per mapping
Source backend@company.com, destination company/engineering/backend. One mapping per sync team keeps each one easy to pause and reason about.
5. Exclude, pin, preview
- Exclude group owners whose membership is deliberate and shouldn't depend on a Google Group.
- Pin permanent users for bots, CI accounts and anyone who needs access without being in the Google Group.
- Read the preview. On a group that's been maintained by hand, expect removals. Each one should be someone who truly shouldn't have access. If not, fix the Google Group first.
6. Notifications, then run
@SyncMyGroups subscribe backend
Every add and remove is posted to a Slack or Microsoft Teams channel, which doubles as a record for access reviews.
Don't run two systems on one group
If you already use SAML Group Sync, don't point a sync tool at the same GitLab groups. GitLab's SAML Group Sync removes users who aren't in the mapped SAML group, and a sync tool will add back whoever the Google Group contains. If the two disagree, membership flips between them. Pick one per group. See one-way vs two-way group sync for how to choose a single writer.
Related workflows
- GitHub too? If some teams are on GitHub, see syncing GitHub teams with Google Groups and the Google Group → GitHub workflow.
- Slack handles that match GitLab groups. Drive
@backendfrom the same Google Group with Google Group → Slack. - Offboarding. Removing someone from the Google Group removes them from GitLab and everything else mapped to it.
Browse all workflows for the full list.
FAQ
Does GitLab's SAML Group Sync work with Google Workspace?
It can. Google Workspace SAML apps can include group membership in the SAML response (up to 75 groups), and GitLab's SAML Group Sync reads groups from that response. It needs GitLab Premium or Ultimate, and membership only updates when users sign in through SAML.
Can I use SCIM between Google Workspace and GitLab.com?
GitLab's 2026 documentation lists Okta and Microsoft Entra ID as supported SCIM identity providers. Google Workspace isn't among them, so SCIM isn't the supported route if Google is your directory.
Do subgroup members get access to the parent group?
No, inheritance flows downward. Members of a parent group are inherited members of its subgroups and projects, not the other way round. Map broad Google Groups to higher levels only when you mean to grant access to everything below.
Does a sync remove people who are only in GitLab?
In a one-way Google → GitLab sync, yes: anyone in the GitLab group who isn't in the Google Group, and isn't a permanent user or excluded, is removed. Read the preview before the first run.
Preview a Google Group → GitLab sync in SyncMyGroup. It's free up to 5 users. See pricing or book a walkthrough.