Google Workspace group sync

Keep EmbayLMS group membership in step with your Google Groups. Where Okta and Microsoft Entra ID push groups into EmbayLMS over SCIM 2.0, Google Workspace has no SCIM push — so EmbayLMS pulls membership instead: a Google Cloud service account you control reads your Google Groups through the Admin SDK Directory API (read-only), on a schedule and on demand.

Why a scheduled sync and not sync-at-login? The Google SSO id_token carries no group information, and listing a user’s groups requires the SDK Directory API with admin privileges — so membership cannot be read from the user’s own login token. A tenant-granted service account with domain-wide delegation is the workable mechanism: EmbayLMS syncs every mapped group every 6 hours, and admins can trigger an immediate Sync now.

How the sync behaves

• Each mapping links one Google group (by its email address) to one EmbayLMS group. Several Google groups may feed the same EmbayLMS group — the membership is the union.
• Google members are matched to EmbayLMS users by email address. Emails without a matching active account are counted and reported, never created — user provisioning stays with SCIM, CSV import, or SSO just-in-time provisioning.
• Members added by the sync are tagged internally (source: google). When they leave the Google group, the next sync removes them. Members added manually in EmbayLMS are never removed by the sync.
• Nested Google groups are flattened: members of a group inside a mapped group are included.
• Every membership change is written to the tenant audit log — actor system for scheduled runs, the requesting administrator for Sync now.
• The service-account key is encrypted at rest (AES-256-GCM) and is never displayed again after you save it; only its client_email fingerprint and sync status are shown.

Prerequisites

• An EmbayLMS plan that includes SCIM provisioning (the same entitlement gates both provisioning mechanisms).
• Owner access in EmbayLMS (the SCIM settings surface).
• Super admin access to your Google Workspace Admin console, and access to a Google Cloud project.

Step 1 — Create a service account (Google Cloud console)

1. In the Google Cloud console, select or create a project, then open IAM & Admin → Service Accounts.
2. Click Create service account. Name it e.g. embaylms-group-sync. No project roles are needed — access comes from domain-wide delegation.
3. Open the new service account → Keys tab → Add key → Create new key → JSON. Download the key file — you will paste its full contents into EmbayLMS in Step 3.
4. On the service account’s Details tab, copy the Unique ID (a long numeric client ID). You need it for Step 2.

Step 2 — Authorize domain-wide delegation (Google Admin console)

1. In the Google Admin console (as a super admin), go to Security → Access and data control → API controls.

2. Under Domain-wide delegation, click Manage domain-wide delegation → Add new.

3. Paste the service account’s Unique ID as the Client ID.

4. In OAuth scopes, enter exactly these two scopes, comma-separated:

   https://www.googleapis.com/auth/admin.directory.group.readonly,
   https://www.googleapis.com/auth/admin.directory.group.member.readonly

5. Click Authorize. Both scopes are read-only — EmbayLMS can list groups and members, nothing else.

Step 3 — Connect EmbayLMS

1. In EmbayLMS, go to Settings → User Management → SCIM Provisioning and find the Google Workspace group sync section.
2. Paste the full JSON key file from Step 1 into the service-account field.
3. Enter the email address of a Google Workspace administrator — the service account impersonates this admin (that is what domain-wide delegation means) to read group membership.
4. Click Connect. EmbayLMS validates the key and delegation live with one Directory API call before saving; if the call fails, nothing is stored.

Step 4 — Map Google groups to EmbayLMS groups

1. In the Group mappings section, start typing the Google group’s name or address in the Google group field (at least two characters). EmbayLMS searches your Workspace directory as you type and lists the matching groups. Pick the one you mean — its address and display name are taken from the directory, so a mistyped address can no longer be saved. The search matches the start of the name or the address (that is what the Directory API offers), so sales finds Sales Team and sales-team@…, but not EMEA sales.
2. Pick the EmbayLMS group it should feed. Only static groups can be mapped — dynamic groups are rule-managed.
3. Click Add mapping. Repeat per group.
4. Click Sync now to run immediately, or wait for the next scheduled pass (every 6 hours). Each mapping row shows its last sync time, member count, and how many emails had no matching account.

Unverified mappings

A mapping carries an Unverified badge until the directory has confirmed its group exists. Mappings created before 2026-09-10 were typed by hand and all start out unverified; every sync checks each mapping against the directory, stamps it verified when the group is found, and refreshes its display name at the same time. If the group has since been deleted in Workspace, the badge comes back and the sync’s error list names the mapping — remove it, or map the group’s replacement. An unverified mapping never moves members, so the badge is worth acting on rather than ignoring.

If the field shows “The directory could not be searched”, the connection is missing, paused, or its delegation was revoked — the message links back to the connection settings above.

Configuration reference

Troubleshooting

Limitations (v1)

• No user provisioning — unmatched emails are reported, not created.
• Sync direction is one-way: Google → EmbayLMS. Membership changes made in EmbayLMS are not written back to Google.
• Removing a mapping or disconnecting keeps the members the sync already added; clean up membership in the Groups admin if needed.