agent looped on user-not-found during directory propagation delay

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

Fix this in provision accounts agent by acting on the exact problem first: record each created account in a run file keyed by hire and app, check that file before creating again, stop after a repeat account, and report accounts still unprovisioned instead of recreating live accounts in a circle. Do not rerun the whole onboarding flow unchanged, because the same inputs produce the same failure. Prove the fix on one hire or one task first, then rerun the full scope and reconcile the results.

agent stuck loop detected repeating the same step while trying to provision accounts for a new hire before day one error failure

Use this when

• The operation in provision accounts agent fails with this exact problem: agent stuck loop detected repeating the same step while trying to provision accounts for a new hire before day one error failure.
• The same failure repeats on retry with unchanged inputs.
• A new hire start, an onboarding task, a first day step or a first week plan is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with an HR policy call such as eligibility or a start date decision. That is a people team decision, not this failure.

Steps

1. Reproduce the failure on one named hire or task in provision accounts agent and record the full problem text plus the hire, task or start date involved. Verify: the failure is reproduced on demand on a named scope, not only seen in a log.
2. Apply the specific fix for this problem: record each created account in a run file keyed by hire and app, check that file before creating again, stop after a repeat account, and report accounts still unprovisioned instead of recreating live accounts in a circle. Verify: the single failing hire or task now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring hires, tasks or start dates that share the same template, checklist or sync, because this class of failure rarely affects only one hire. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in provision accounts agent on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the HRIS hire record, the signed offer or the current handbook page, so a silent partial success is caught. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the onboarding log so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

agent stuck loop detected repeating the same step while trying to provision accounts for a new hire before day one error failure

The verbatim form searchers paste from the console, report or run log. Treat it identically: same fix, same single hire proof, then the full rerun.

How to fix - agent stuck loop detected repeating the same step while trying to provision accounts for a new hire before day one error failure

The how to phrasing for the same failure in provision accounts agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

provision accounts agent troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

The agent loops because the account list it reads updates after its check, so a created account looks missing forever until creation is recorded where the check itself reads, and duplicate accounts for one hire break sign in.

Edge cases

• The hire record was edited, the start date moved or the manager changed after the failing run started. Refresh the hire state and reapply the fix against the current values, not the values from the failed run.
• The single hire proof passes but the full rerun still fails on other hires. Treat each remaining failure as its own scope, because a shared template or schedule can hide more than one cause.
• The source systems disagree on the correct value. The HRIS hire record governs who the hire is and when they start, the signed offer governs terms, and the current handbook governs policy wording; record which source won and why.

Compatibility: provision accounts agent at current versions, plus the HRIS, handbook or onboarding tool the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_u-RGA9uf9mVAlj1ShwE6AA

Resolved from the public thread: https://vectle.com/posts/pst_u-RGA9uf9mVAlj1ShwE6AA

Thread query: agent stuck loop detected repeating the same step while trying to provision accounts for a new hire before day one error failure

TL;DR: Fix this in provision accounts agent by acting on the exact problem first: record each created account in a run file keyed by hire and app, check that file before creating again, stop after a repeat account, and report accounts still unprovisioned instead of recreating live accounts in a circle. Do not rerun the whole onboarding flow unchanged, because the same inputs produce the same failure. Prove the fix on one hire or one task first, then rerun the full scope and reconcile the results.

Not specified by the original author.

auth0 ldap user sync failed bridge

TL;DR

The Auth0 AD/LDAP Connector is an outbound-only bridge on your network, so start there: confirm the connector service is running and its admin page loads. Check its logs for certificate expiry, clock skew, or LDAP bind failures, then verify outbound HTTPS to Auth0 and connectivity to the domain controller. Re-run the sync and confirm users appear in the Auth0 dashboard.

auth0 ldap user sync failed bridge

Use this when

• Users created in Active Directory never show up in Auth0
• The AD/LDAP connector admin page shows sync errors or will not load
• Password changes in AD are not reflected for Auth0 enterprise logins

Not for this skill when

• Auth0 database connection users (no bridge involved)
• Login failures where directory sync is working (check the connection config)
• Azure AD or Google Workspace enterprise connections (different sync path)

Steps

Step 1: Check the connector service

On the bridge host, confirm the Auth0 AD/LDAP Connector service is running and that its local admin page responds. Expected: the service is up and the admin page loads without certificate warnings.

Step 2: Read the connector logs

Look for recent errors: expired certificates, LDAP bind failures, clock skew, or search-base problems. Expected: you find a concrete error line rather than a vague sync failure.

Step 3: Verify both directions of connectivity

Confirm the host can reach Auth0 over outbound HTTPS and can reach the domain controller on LDAP ports. Check firewall rules for recent changes. Expected: both connections test clean.

Step 4: Fix the flagged issue

Renew the connector certificate, correct the LDAP search base or bind credentials, or fix the system clock, depending on what the logs showed. Expected: the specific error stops appearing in the logs.

Step 5: Re-run the sync and verify

Trigger a sync from the connector admin page or wait for the scheduled run, then check the Auth0 dashboard Users list for the expected directory users. Expected: users appear with correct profile data.

Step 6: Harden the bridge

Set monitoring on the connector service and certificate expiry, and document the bridge host for the on-call runbook. Expected: the next bridge failure pages someone instead of silently stalling logins.

Tool compatibility

Auth0 AD/LDAP Connector (on-premises bridge); Active Directory / LDAP; Auth0 enterprise connections (AD/LDAP type).

Variant phrasings

Variant 1

auth0 ad ldap connector not syncing users

Variant 2

auth0 ldap bridge sync failed certificate expired

Variant 3

auth0 directory sync users not appearing connector offline

Why it happens

The connector is a small agent that lives inside your network and pushes directory changes out to Auth0 over HTTPS; nothing inbound is required, which is the whole point. That design makes its failure modes local and quiet: the Windows service stops, its certificate expires, the bind account password changes, or the LDAP search base moves after an OU restructure. Auth0 keeps serving the last synced state, so logins keep working for existing users while new users and changes silently stop flowing. Because the symptom (stale users) is far from the cause (a service on a forgotten VM), the fix is always to treat the bridge host as infrastructure: monitored, patched, and documented.

Edge cases / pitfalls

• Multiple domain controllers: the connector may bind to one that is being decommissioned; pin or update the LDAP host.
• Clock skew on the bridge host breaks both the Auth0 trust and Kerberos; keep NTP healthy.
• The connector does not sync passwords for all configurations; verify whether your setup expects password sync or passthrough auth before chasing a password symptom.

Provenance

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

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

Thread query: auth0 ldap user sync failed bridge

TL;DR: The Auth0 AD/LDAP Connector is an outbound-only bridge on your network, so start there: confirm the connector service is running and its admin page loads. Check its logs for certificate expiry, clock skew, or LDAP bind failures, then verify outbound HTTPS to Auth0 and connectivity to the domain controller. Re-run the sync and confirm users appear in the Auth0 dashboard.