Google Workspace user provisioning failed: admin SDK error user not found fix

TL;DR

Fix the lookup, not the hire record. The Admin SDK returns user not found when the provisioning step queries by an alias, a renamed primary email, or before the new account has replicated. Standardize lookups on the immutable user id or the exact primary email, add a create-then-wait check with retry, and confirm the account exists in the Admin console before any group or license step runs against it.

Google Workspace user provisioning failed: admin SDK error user not found

Use this when

• A provisioning script or connector fails with a user not found response from the Directory API.
• The hire account was just created, renamed, or moved between organizational units.
• Group, license, or profile update steps fail while the account itself exists in the Admin console.

Not for this skill when

• The Admin console also shows no account and the create step itself failed. Fix the create error first.
• The whole Workspace org returns errors for every user. Check domain verification and service status instead.

Steps

1. Reproduce the lookup manually in the Admin console search and in the Directory API explorer using the exact key the automation sent, then repeat with the primary email and with the user id. Note which keys resolve and which return not found, because alias and nickname keys behave differently from primary keys. Verify: you know exactly which identifier form fails
2. Check the hire timeline. If the lookup ran within minutes of account creation or a primary email rename, treat replication delay as the prime suspect and re-run the single failed step after a short wait. Confirm the account shows as active and not still being created in the console. Verify: the delayed retry resolves the user without any record change
3. If the delay theory does not hold, inspect the provisioning source for the key it builds, looking for a personal email, an old domain, a plus suffix, or a display name passed where an email belongs. Correct the mapping so the HR record supplies the corporate primary email and, after create, the returned user id is stored for all later steps. Verify: the corrected mapping shows primary email and stored id for a sample hire
4. Confirm the service account or delegated admin running the automation has scope to read users in the target organizational unit, because a user outside the delegated scope can present as not found. Test with a full admin lookup for comparison and narrow the difference. Verify: the automation identity resolves the same user the admin found
5. Re-run the full provisioning sequence for the affected hire in order, create check, profile update, group adds, license assignment, and confirm each step references the stored id. Watch for any step still building its own email key from an HR field that can change. Verify: every step succeeds for the hire with no not found response
6. Harden the workflow by adding a resolve step after creation that polls the Directory API until the user resolves or a timeout alerts an operator, and log the resolved id on the onboarding ticket. Verify: a test hire completes with the resolve step logging a valid id before downstream steps run

Why it happens

The Directory API resolves users by primary email, alias, or immutable id, and each form has different timing and visibility rules. A freshly created or renamed account may not be searchable by every key immediately, aliases can be removed during onboarding standardization, and a delegated admin cannot see accounts outside its scope, which the API also reports as not found. Provisioning chains that rebuild an email key at every step multiply these failure points. Anchoring the chain on the id returned at creation removes most of them at once.

Variants and edge cases

Not found only for group membership steps

Group APIs resolve members by email and reject ids in some calls. Resolve the primary email from the stored id immediately before the group call instead of reusing the HR email field.

Not found after a domain rename project

During domain migrations the primary email changes while HR still sends the old domain. Update the HR domain mapping on the cutover date, not after failures accumulate, and keep the old address as an alias during transition.

Intermittent not found across many hires

Sporadic failures at volume usually mean replication timing, not bad records. Add the polling resolve step and spread bulk creates over a longer window instead of parallel bursts.

Compatibility: Applies to Google Workspace Admin SDK Directory API v1 used by GAM, custom scripts, and HR provisioning connectors. Requires a Workspace admin with user read rights for diagnosis.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_naniosfVCxx6Wa2Tv7uxdg