Connect one authoritative identity source, test deprovisioning and group changes end to end, and define an emergency manual path before relying on SCIM.
Update — August 12, 2026: This guide now covers the Google-managed service account, long-lived API keys, locked synced groups, and the audit trail required to operate the connection safely.
Google Workspace inbound SCIM APIs are generally available, allowing Workspace to receive real-time identity changes from a compatible identity provider, HR system, or custom application. Google Workspace acts as the SCIM service provider, while the external system becomes the source that provisions, updates, and deactivates users and groups.
The most important benefit is not faster onboarding. It is reducing the period in which a former employee or transferred worker retains access because two directories disagree.
What changes operationally
A permission change in the identity provider can update access to Workspace data and downstream applications such as Gemini Enterprise. Administrators can generate a token, connect the external directory, and lock synchronized groups against conflicting manual edits.
Google says the feature is available by default, can be controlled at domain level, and is rolling out across Business and Enterprise Starter, Standard, and Plus editions.
Choose an authority before connecting systems
SCIM solves transport, not ownership. Decide whether the HR system or identity provider owns names, employment status, managers, groups, and role changes. If two systems can edit the same field, automation may make the conflict faster rather than remove it.
Map every lifecycle event: pre-hire, start date, leave, return, role transfer, contractor expiration, termination, and legal hold. Not all departures should trigger identical data handling.
Test the dangerous direction
Pilots often prove that an account can be created and stop there. Test deactivation, group removal, reactivation, token expiration, source downtime, duplicate identities, and an incorrect termination event. Confirm what happens to files, calendars, delegated access, and downstream apps.
Keep a monitored break-glass procedure for urgent manual suspension. Automation should shorten exposure, not prevent an administrator from acting when the source system fails.
Treat the SCIM connection as a privileged integration
When an inbound SCIM connection is created, Google creates a Google-managed service account with User Management Admin and Groups Admin roles. The API keys authenticate that account for directory-update requests. The keys are managed in the Workspace Admin console, do not appear in the Google Cloud console, and can be used only for the Cloud Identity SCIM endpoint.
That is a purposeful boundary, but it makes key custody important. The setup screen shows a generated key only once, allows up to two keys, and supports deletion and regeneration. Store it in the identity platform or an approved secret manager, restrict who can create or rotate it, and rehearse a rotation without relying on a copied key in a ticket or document.
Lock groups deliberately and watch the audit trail
Synced groups are locked by default so manual Workspace edits do not conflict with the external source. Once an administrator manually unlocks a processed group, later SCIM requests do not re-lock it unless the connection settings change. That exception can be useful during an incident, but it can also quietly create a second source of truth.
Google provides inbound-SCIM audit events for connection creation, configuration changes, deletion, API-key creation, and API-key deletion. Add those events to the identity change-review process. An unexpected new key, deleted connection, or group-unlock decision should be investigated with the same urgency as a change to an administrator role.
- Assign an owner for the external source, the Workspace connection, and the emergency suspension path.
- Store the API key only in an approved secrets system and test rotation before the first production emergency.
- Decide whether synchronized groups remain locked and document each manual unlock with an expiry or follow-up task.
- Review SCIM audit events after setup, key rotation, and significant identity-provider changes.
- Test service-account and key removal behavior before decommissioning a connection.
This article explains the practical implications of the primary material below. PatchMemo does not publish vendor copy as editorial coverage and does not accept payment for positive coverage.
PatchMemo independently selects and evaluates the topics it covers. Analysis and recommendations are ours; sources are linked so readers can check the underlying claims. We clearly label sponsorships and affiliate relationships, and neither determines coverage or conclusions.
