Okta and Microsoft Entra Deprovisioning for Google Workspace: What It Does and What It Leaves Behind

By Patronum

November 13, 2026

Read Time: 7 mins

Okta and Microsoft Entra Deprovisioning for Google Workspace: What It Does and What It Leaves Behind image

What does Okta do to a Google Workspace user when you deactivate them?
What does Microsoft Entra ID do to a Google Workspace user?
Your IdP does / You still need to do
Why does the IdP’s timing matter for calendars?
An example: Friday afternoon with Okta
How Patronum picks up the Google side
FAQ
Sources

When you deactivate or unassign a user in Okta or Microsoft Entra ID, the Google Workspace connector suspends the Google account, when deprovisioning is enabled and the connector has permission to manage that user. It doesn’t delete the account, and it doesn’t move Drive files, calendars, group ownership or mail. The data handover is still yours to run.

This page covers the leaver side only. For the wider joiner, mover and leaver picture, see Google Workspace user provisioning.

What does Okta do to a Google Workspace user when you deactivate them?

Okta suspends the Google account, as long as deprovisioning is switched on. Okta lists Deactivate Users among the provisioning features you enable before it manages Google users, and Google’s own Okta setup guide sets Deactivate users to enabled on the Provisioning tab. Google’s guide also has you make Okta’s provisioning account a super admin so it can create, list and suspend users (Google Cloud).

With that in place, Okta’s default is to suspend the user in Okta and in Google when no deactivation option is selected. The Deactivation options on the user or group assignment change that (Okta):

Okta deactivation option	What Okta’s documentation says
None selected (default)	The user is suspended in Okta and in Google
Do not suspend user	The Google account stays active
Remove all G Suite licenses	The user’s Google licenses no longer exist in Okta after deprovisioning
Remove all G Suite Roles	The user’s Google roles no longer exist in Okta after deprovisioning

Read the last two rows carefully. Okta describes them in terms of what Okta holds, and its page doesn’t spell out the exact change on the Google side. Okta also says it can manage only custom roles created in Google, not Google’s default roles. So after an Okta deprovisioning, check the user’s licenses and admin roles in the Google Admin console yourself, Super Admin included.

Be careful with licenses in particular. Google warns that removing a user’s license can lose their data and points you to archiving instead (Google). Don’t let any tool pull the license until the mail and files are safe.

Okta stops short of deletion on purpose. Its Google Workspace provisioning page calls deletion destructive, because it removes the email, documents and other content the user created, and leaves the user inactive so admins can clean up first (Okta).

What does Microsoft Entra ID do to a Google Workspace user?

Microsoft Entra ID also suspends rather than deletes in the normal leaver cases. Microsoft’s Google Workspace tutorial says that removing a user from the sync scope disables them in Google without deleting them (Microsoft Learn). Google’s architecture guide maps both a disabled user and an Entra soft delete to a suspended Google user (Google Cloud).

The open question is the hard delete. Microsoft’s general provisioning documentation, which describes a service built on the SCIM 2.0 protocol, says a user hard-deleted in the source is deleted in the target app, and that Entra hard-deletes users 30 days after a soft delete. The same page says gallery apps can behave differently from those generic rules (Microsoft Learn). We haven’t found documentation of what the Google gallery connector does on day 30. Treat that as unresolved: finish the Google handover well before day 30 as a precaution, and read your provisioning logs to see what Entra actually sent.

Three more Entra details affect planning:

Timing. Microsoft’s tutorial says the synchronization cycle runs every 40 minutes, so a suspension isn’t instant.
Licenses. Google’s Entra guide says the Microsoft connector currently can’t assign licenses and suggests automatic licensing by organizational unit (Google Cloud). Reclaiming a license is a Google-side job.
Admins. If Entra’s account in Google is a delegated admin rather than a super admin, Google’s guide says it can’t manage other delegated admins or super admins. A departing admin may never be suspended by Entra at all.

Your IdP does / You still need to do

A suspended account keeps nearly everything. Google says a suspended user’s email, documents and calendars aren’t deleted, collaborators keep their access to shared files, and suspended accounts are billed like active ones (Google). Here’s how the work splits:

Your IdP does (Okta or Entra ID connector)	You still need to do (in Google Workspace)
Suspends the Google account, so the user can’t sign in	Transfer My Drive files to an active owner or a shared drive; Google requires a recipient whose account is active (Google)
Okta options touch licenses as Okta tracks them	Decide how to keep the mailbox before any license change
Verify role changes in Google; Okta documents custom-role management	Check pre-built admin roles, including Super Admin
Syncs group membership if you push groups	Hand over Google Groups the leaver owns and remove them from groups the IdP doesn’t manage
Nothing for calendars	Transfer secondary calendars before suspension, then transfer or cancel the events they organized
Nothing for mail flow	Decide how future mail to the address is handled
Nothing for sharing	Review files the leaver shared outside the company
Nothing for legal holds	Confirm with the legal or records owner whether a Vault hold applies

Groups need attention sooner than you’d think. Google says group messages bounce automatically when more than 66% of a group’s members are suspended, and recommends removing suspended users from groups as part of termination (Google).

Why does the IdP’s timing matter for calendars?

Because the IdP suspends first, and some calendar work has to happen before that. Since October 2026, Google has been rolling out a change so that a user’s owned secondary calendars are suspended along with the user, and Google advises transferring ownership before the account is suspended or deleted (Google Workspace Updates).

Anything that starts after the IdP’s suspension, whether a manual task or an automated policy, may be too late for shared team calendars the leaver owned. For a planned departure, transfer secondary calendars during the notice period. The leaver’s primary-calendar events are a separate job; we cover both in what happens to Google Calendar events when an employee leaves.

An example: Friday afternoon with Okta

HR ends a sales manager’s contract on Friday. Okta deactivates her and, with the default options, suspends her Google account. Sign-in is blocked, which is what you wanted.

On Monday, her proposals still sit in her My Drive and are still shared with customers. She still organizes the weekly pipeline meeting and owns the sales team’s Google Group. Customers who email her get nothing back. None of that is a fault in Okta. It’s the part of offboarding that lives inside Google Workspace.

How Patronum picks up the Google side

Patronum is a no-code Google Workspace management platform whose offboarding policies run the data handover inside Google Workspace after your IdP has dealt with identity. You scope a policy to all users, an organizational unit or a Google Group, then narrow it with conditions such as Last Sign In, End Date or Suspended (Patronum). Policies run hourly by default (Patronum).

Two patterns fit an IdP setup:

Suspended condition. The IdP suspends the account and a policy filtered on Suspended picks the user up on a later run. Because that runs after suspension, transfer secondary calendars beforehand.
Offboarding OU. Move the leaver into a dedicated offboarding OU, the typical pattern in Patronum’s help, and scope the policy to it. This lets the handover start before the IdP suspends, if your process moves the user first.

Patronum reads the account’s state in Google. It isn’t documented as listening for Okta or Entra events, so test the hand-off with a test user before you rely on it.

Documented offboarding actions include (Patronum):

Transfer Drive files to a person or a shared drive, and remove external or internal file access, with a file-sharing report.
Remove the user from Google Groups and transfer group ownership.
Transfer primary and secondary calendars, delete all or future events, remove the user as an attendee and remove them from shared calendars.
Remove the user from Admin console roles and Google Chat spaces.
Remove licenses, or assign an Archived User or Cloud Identity Free license.
Set email forwarding, or rename the user and assign the old address to a Google Group.
Archive the leaver’s email (Mbox) and Google Vault data to your own Google Cloud Storage bucket with Patronum Archive. Archive doesn’t cover Drive, Calendar or Chat.

Two decisions stay with you. Which mail continuity route fits the address, and whether a legal hold applies, need their own owners and sign-off; a policy carries out the choice but doesn’t make it. Patronum’s onboarding page also says it supports IDaaS providers including Okta, OneLogin, Namely and PingIdentity (Patronum). That’s Patronum’s own description; design around the documented scope and conditions.

FAQ

What should happen first if a leaver must lose access right now?

Containment. Let the IdP suspend the account, or suspend it in Google, and do the data handover afterward. Accept that owned secondary calendars may be suspended with the account. Our immediate offboarding guide covers the order.

Does suspending a user through Okta or Entra stop Google billing?

No. Google bills suspended accounts like active ones. To stop paying for the seat, decide how to keep the mail, then change the license or delete the account in Google.

Can Okta or Entra ID transfer a leaver’s Google Drive files?

Neither connector’s documentation describes moving files. Use the Admin console transfer tool or an offboarding policy. See transferring Google Drive file ownership.

If your IdP already suspends leavers on time, the account-suspension step is handled. See how Patronum’s offboarding policies run the Drive, group and calendar handover that follows, with an execution log for every run.