Sync Google Groups to Jira and Atlassian Groups Without Atlassian Guard

In Jira and Confluence, groups do the heavy lifting. Permission schemes grant browse and edit rights to groups. Project roles reference groups. Confluence space permissions, issue security levels, and automation rules all point at them. If those groups don't match reality, people either can't see what they need or can see things they shouldn't.

Most Google Workspace companies already have that reality written down as Google Groups: support@, finance@, eng-platform@. The natural question is how to make the Atlassian groups follow the Google ones. Atlassian has an answer, but the useful part of it sits behind a paid add-on. This post walks through what's included, what isn't, and how to fill the gap.

What Atlassian gives you for Google Workspace (as of 2026)

Atlassian's admin lets you connect Google Workspace to your Atlassian organization. Per Atlassian's documentation, checked September 2026, the feature is available on all plans (except Atlassian Government Cloud), but the capabilities depend on whether you subscribe to Atlassian Guard Standard — the product previously sold as Atlassian Access.

Capability	Without Guard	With Guard Standard
Sync users from Google Workspace	Yes — all users into one group	Yes
Sync specific Google Groups with their members	No	Yes
Automatically deactivate Atlassian accounts when you suspend, archive or delete the Google account	No — deactivate manually	Yes
Sync frequency	Every 4 hours	Every 4 hours

Atlassian's pricing page (October 2026) lists Guard Standard at $4.35 per user per month and Guard Premium at $8.55 per user per month. Because it's priced per user, the cost scales with your headcount, not with the number of groups you need to sync.

To be fair to Guard: it isn't only group sync. Standard also includes SCIM provisioning and de-provisioning with identity providers, and Guard covers broader security controls. If you need those, it may well be worth it. But if the thing you actually want is "make jira-support match support@acme.com", paying for Guard across every user is a lot of money for one feature.

Groups vs teams in Atlassian

Before mapping anything, be clear on which Atlassian object you mean.

• Groups are admin objects. They grant app access and are used in permission schemes, project roles and space permissions. This is what most people mean by "Jira groups".
• Teams are collaboration objects. They show up in Jira for assigning work, in plans, and on people profiles, and they're mainly about collaboration rather than access control.

SyncMyGroup syncs both Jira / Atlassian groups and teams. For access control, sync into groups. For "who is on the platform team" in planning and assignment, sync into teams. Many companies want both, from the same Google Group. If you also want Atlassian teams reflected in Slack, see Sync Jira teams to Slack user groups.

Option 1: Keep doing it by hand

Small companies often do. An admin adds new hires to the right Jira groups when IT tells them to. The failure mode is predictable: additions happen because someone is blocked and complains; removals don't happen because nobody is blocked. Six months later, the finance-confidential group has people from three reorgs ago.

If you stay manual, at least run a quarterly comparison of each Atlassian group against its Google equivalent. Atlassian's admin lets you export users and groups; Google's Admin console and the Directory API give you group members. A spreadsheet diff is crude, but it catches the worst drift. See group membership drift and access reviews for a more structured approach.

Option 2: Script it

The Atlassian side has public APIs for group membership (the Jira Cloud REST API has group member add and remove endpoints, and there's an organization-level admin API). A script that reads a Google Group via the Admin SDK Directory API and reconciles the matching Atlassian group is doable.

What makes it harder than it looks:

• Account IDs. Atlassian identifies users by account ID, not email. You need a reliable email-to-account-ID lookup, and some accounts hide their email depending on profile visibility settings.
• Nested Google Groups. The Directory API returns nested groups as members of type GROUP. Expand them, or your Jira group quietly misses everyone in the sub-groups.
• App access groups. Some groups grant access to a Jira or Confluence app. Removing someone from such a group can remove their access to the app, which is exactly right for leavers and exactly wrong if your mapping is mistaken.
• Maintenance. Token rotation, API changes, error handling, and someone to own it.

Option 3: A purpose-built group sync

SyncMyGroup connects Google Workspace and your Atlassian site and keeps chosen Atlassian groups and teams matching chosen Google Groups.

1. Connect Google Workspace and Jira / Atlassian at app.syncmygroup.com.
2. Create a sync from support@acme.com to the jira-support group. If the destination group doesn't exist, it can be created; groups can also be deleted when their source is removed.
3. Nested Google Groups are supported, so support@ containing support-tier1@ and support-tier2@ produces the full membership in Jira.
4. Filters and exclusions. Exclude all-company lists and external aliases from discovery, and exclude individual users such as service accounts.
5. Permanent users. Keep Jira admins or an integration user in a group no matter what Google says.
6. Preview first. See every add and remove before anything is written. On the first run, look hard at the removals — they're the people your permission schemes have been trusting without anyone checking.
7. Notifications. @SyncMyGroups subscribe <team> in a Slack or Microsoft Teams channel posts every change, which is useful evidence for access reviews alongside SyncMyGroup's audit logs of sync operations.

One thing group sync isn't: account provisioning. It manages who is in which group. People still need Atlassian accounts, which the free Google Workspace connection (all users into one group) can handle. A common low-cost setup is:

• Atlassian's free Google Workspace connection for accounts.
• SyncMyGroup for specific group and team membership.
• A clear offboarding step for deactivating accounts (see The offboarding gap), since automatic deactivation is a Guard Standard feature.

A worked example

Say you have a 120-person company on Google Workspace with a Jira Service Management project for internal IT and a Jira Software project per engineering team.

Google Group	Atlassian destination	Used for
it@acme.com	jsm-it-agents group	Agent access in the IT service project
eng-platform@acme.com	platform group + Platform team	Project permissions, assignment, plans
eng-data@acme.com	data group + Data team	Same
finance@acme.com	confluence-finance group	Restricted Confluence space
everyone@acme.com	excluded	Too broad to be a permission group

Five syncs, one preview each, and the Google Groups that HR and IT already maintain now drive Jira and Confluence access. Then add the same groups to Slack (Slack ↔ Jira) and GitHub (GitHub ↔ Jira) so a single change in Google lands everywhere.

The cost comparison

Guard Standard is priced per user per month ($4.35 list on Atlassian's pricing page in October 2026). SyncMyGroup is free up to 5 users, and the Starter plan is $2 per user per month with unlimited users, API access and reporting (pricing). Your real numbers depend on how many users are in scope and what else you'd use Guard for, so run both against your own headcount. If SSO enforcement, SCIM from an IdP, or the other Guard security features are on your roadmap anyway, Guard may be the right purchase and group sync comes with it.

FAQ

Can I sync specific Google Groups to Atlassian without Atlassian Guard?

Not with Atlassian's built-in connection. Per Atlassian's documentation (2026), without Guard Standard all Google Workspace users sync into one group; syncing specific groups with their members requires Guard Standard. A third-party group sync tool can manage specific group membership instead.

How often does Atlassian's Google Workspace sync run?

Atlassian's setup documentation says users sync from Google Workspace every 4 hours once sync is enabled.

Should I sync into Atlassian groups or teams?

Groups for permissions (project access, permission schemes, space permissions), teams for collaboration (assignment, plans, profiles). SyncMyGroup supports both, so you can drive both from the same Google Group.

Does removing someone from a synced group remove their Jira access?

It can, if that group is what grants app access. That's the desired result for leavers, which is why you should preview every sync and check which groups grant app access before the first run.

---

See the preview against your own Google Groups: start free at app.syncmygroup.com or book a walkthrough.