How to Sync Google Groups to Slack User Groups: A Complete Guide (2026)

You have engineering@company.com in Google Workspace and @engineering in Slack. They are supposed to contain the same people. They don't, and they haven't for a while.

This guide covers the three ways to fix that, how to actually set the recommended one up, and — the part most guides skip — the ten specific things that break group sync in production and how to handle each one.

First, understand what you're syncing

Slack has two different objects that people casually call "groups," and they behave differently:

User groups are the @handles — @engineering, @oncall-payments. Mentioning one notifies everyone in it. They're managed through Slack's usergroups.* API methods, and critically, usergroups.users.update replaces the entire membership list in one call. That's what makes them a good sync target: you compute the correct roster and write it whole.

Channel membership is who is actually inside #engineering. Different API (conversations.invite, conversations.kick), different semantics, and for private channels, real access-control implications.

Most teams need both. A Google Group should typically drive the @handle and the channel — otherwise new hires can be mentioned in a channel they aren't in.

On the Google side, note that Google Groups can be nested. all-engineering@ might contain platform@, payments@, and mobile@ rather than individual people. Any sync you build or buy has to flatten nested groups, or it will resolve all-engineering@ to three members instead of sixty.

The three approaches

Option A: Your identity provider (Okta / Entra ID)

If you run Okta or Microsoft Entra ID and every employee flows through it, group provisioning from the IdP is architecturally the cleanest model. One authoritative directory, everything downstream derived from it.

Two catches, and they're significant.

First, Slack's SCIM API requires Business+ or Enterprise plans. On Pro, this path doesn't exist.

Second — and this catches people mid-rollout — SCIM cannot set Slack user group mention handles. Your IdP can create a group and populate it correctly, and your team still won't be able to type @engineering until someone configures that handle by hand. Entra's provisioning also runs on a scheduled cycle of roughly 40 minutes, which is fine for onboarding and poor for offboarding.

Use this if: you're on a qualifying Slack plan, the IdP genuinely reflects your org, and handle management by hand is acceptable.

Option B: Write it yourself

The core loop is genuinely small. Call the Google Admin SDK Directory API to list group members, call users.lookupByEmail in Slack to resolve each to a Slack ID, and call usergroups.users.update with the resulting list. Run it on a cron. A first version is an afternoon's work and it will appear to function.

The maintenance is where the cost lives. Skip ahead to the failure modes section — that list is your real backlog.

Use this if: you have exactly one stable mapping and a named owner who'll still be here next year.

Option C: A purpose-built sync tool

Tools built for this use Slack's regular Web API rather than SCIM, which means they work on any Slack plan and can do the things SCIM can't — set handles, manage channel membership, reconcile in both directions.

SyncMyGroup is the option this guide walks through, because it covers both Slack object types, handles nested groups, and extends to Jira, GitHub, PagerDuty, Opsgenie, Zoom, and Linear when the problem inevitably grows past Slack.

Use this if: you want it working this afternoon, on your current Slack plan, with removals handled properly.

Step-by-step setup

Here's the full flow, roughly fifteen minutes.

1. Connect your integrations

In the app, go to My Integrations, select your workspace, and click Add Integration. Choose the config type — Google Workspace — and authorise. Repeat for Slack.

For the Google connection you'll authorise directory read access so the tool can enumerate groups and members. For Slack you'll install the app with scopes covering user group read/write, user read, and channel management. Read those scopes before approving; your security team will ask, and the answer should be short and specific.

Slack user group management requires the appropriate workspace permission — if your workspace restricts who can edit user groups, the installing account needs that permission or the sync will authenticate fine and then fail on write.

2. Create a sync team

A SyncTeam is one mapping — one source, one destination, one direction, one set of rules. Create one per group pair. Resist the urge to build one giant mapping; separate teams are easier to debug, pause, and reason about.

3. Pick your source

Select the Google Group that will be authoritative — say, engineering@company.com.

This is the decision that matters more than any configuration option. Whichever side you pick as the source wins every disagreement, forever. If Google is the source, then someone adding a person directly to the Slack handle is making a temporary change that will be reverted on the next cycle. Everyone who edits groups needs to know that, or they'll fight the sync and lose trust in it.

4. Pick your destination

Choose the Slack user group (@engineering) or the Slack channel (#engineering) — or set up two sync teams and drive both from the same source.

Direction is set per mapping, so you can have Google → Slack for departments and Slack → Google for a team that genuinely lives in Slack first.

5. Configure filters and permanent members

Before you sync anything:

• Exclusions — Google Groups you never want touched (security-incidents@, board@), and individual users to leave alone.
• Permanent members — people who stay in the destination regardless of the source. This is for integration bots, the on-call alias, the exec who wants visibility without being in the directory group. Every real group has two or three of these. Configure them now, not after the first sync removes someone important.

6. Read the preview

Do not skip this. The tool shows you the exact diff — who gets added, who gets removed — before writing anything.

On a group that's drifted for two years, the removal list will be long, and some entries will be wrong. That's not the tool malfunctioning; it's your nominal source of truth turning out to be incomplete. Fix the Google Group, add permanent members for the genuine exceptions, and re-preview until the diff is one you'd defend in writing.

7. Turn on notifications, then activate

Point the @SyncMyGroups bot at an ops channel so every add and remove is logged somewhere visible. This is your audit trail and your early warning when a mapping is wrong.

Then activate. Watch one full cycle before adding a second mapping.

The ten things that break group sync

This is the section worth bookmarking. Whether you buy or build, these will happen.

1. Email mismatch. Someone's Slack account uses p.sharma@company.com, their Google primary is priya@company.com. Email-based matching silently skips them. Always review the unmatched-users list; it's where the surprises live.

2. Nested groups. all-engineering@ contains three groups, not sixty people. Unflattened, you sync three members. Confirm your tool flattens nesting, or flatten it in the source.

3. Deactivated accounts. Order matters: you usually cannot remove a deactivated user from a group after deactivation. Remove from groups first, then deactivate — otherwise the stale membership record is stuck permanently.

4. Contractors on external domains. They're in the Slack channel and not in the Google Group, because they don't have a company Google account. Permanent members, or a dedicated group for them.

5. Bots and integrations. The deploy bot lives in #engineering and will never be in a Google Group. Permanent members.

6. Rate limits. Bulk changes across hundreds of users hit Slack and Google API limits fast. A naive script retries hard and makes it worse. Backoff, or let a tool that already handles it do the work.

7. Groups used for licensing. Adding thirty people to an Atlassian group can add thirty billable seats. Check license headroom before the first sync, not after the invoice.

8. Private channel access. Syncing private channel membership grants access to content. Treat these mappings as an access-control change and get sign-off.

9. The bidirectional loop. Two-way sync between systems that both mutate creates flapping — A adds, B removes, repeat. Pick one owner per destination. If you genuinely need two-way, understand the conflict resolution rules first.

10. Silent failure. The token expires, the sync stops, and nobody notices for six weeks because nothing visibly broke. This is the most common real-world failure by a wide margin. Notifications aren't a nice-to-have — an ops channel that goes quiet is the only signal you'll get.

How often should it run?

The right cadence depends entirely on what the group gates.

Departmental groups — @marketing, @engineering — change a few times a month. A cycle measured in minutes is more than sufficient, and there's no benefit to going faster.

Access-bearing groups — anything that grants repository access, Jira project permissions, or private channel membership — should reconcile as quickly as your tooling allows, because the offboarding case is the one that matters. The gap between "removed in the directory" and "removed everywhere" is your exposure window, and a 40-minute IdP cycle is a 40-minute window.

On-call handles need to flip within a couple of minutes of a schedule change. A rotation that hands over at 09:00 and updates the Slack handle at 09:45 has produced a handle that is confidently wrong during the exact window someone is most likely to use it.

If you're building this yourself, this is an argument for event-driven updates over a nightly cron. If you're buying, it's a question worth asking the vendor directly rather than inferring from the marketing page.

What "working" actually looks like

You'll know the setup is healthy when three things are true.

The ops channel is boring but not silent. A steady trickle of add/remove notifications that match real joiners and leavers. Total silence means something has stopped and nobody noticed.

Nobody edits the destination by hand any more. If people are still manually adding members to @engineering, either the source is wrong or the team doesn't trust the sync. Both are fixable, and both are worth fixing — a sync people work around is worse than no sync, because it creates false confidence.

Offboarding stops generating tickets. The clearest signal. When removing someone from one group removes them from everywhere, the "can someone also remove X from…" messages simply stop arriving.

After it's working

Once one mapping runs cleanly, the pattern repeats cheaply. The obvious next steps:

• Google Group → Slack channel, so the handle and the channel share a source.
• Slack → Jira groups, so project permissions stop requiring a ticket. (Slack → Jira)
• Slack → GitHub teams, so CODEOWNERS routing stays correct. (Slack → GitHub)
• PagerDuty on-call → a Slack handle, so @oncall-payments always contains whoever is actually on call. (Slack → PagerDuty)

That last one tends to be the highest-value automation most teams have never set up.

The compounding benefit isn't the minutes saved per group edit. It's that offboarding becomes a single action instead of an eleven-item checklist that is wrong the moment you save it.

---

Start with one group on the free tier, or read the setup docs at docs.syncmygroup.com. The Google Group → Slack workflow page covers the direction options in more detail.