android work profile setup paused: waiting for your IT admin

Not specified by the original author.

TL;DR

The setup pauses until the admin side is ready: the user needs an Intune license, the enrollment must be approved or configured, and managed Google Play must be connected. Fix the admin side, then have the user retry the setup.

The query

android work profile setup paused: "waiting for your IT admin"

Use this when

• work profile setup shows waiting for your IT admin
• the pause never clears after hours
• one user stuck while others enroll fine

Not for

• fully managed device enrollment failures
• Company Portal install problems
• work profile creation errors with a specific code

Steps

1. Confirm the user has an Intune license and is in scope for MDM enrollment. Expected output: license and scope are verified.
2. Check that managed Google Play is connected in the Intune admin center under enrollment. Expected output: the managed Play connection shows healthy.
3. Look for an enrollment approval workflow or enrollment restrictions holding this user. Expected output: any pending approval is found and approved, or restrictions are confirmed clear.
4. Have the user force-stop the setup, then restart work profile creation from the Company Portal. Expected output: setup proceeds past the waiting screen.
5. Confirm the work profile appears and required apps deploy. Expected output: the work profile is active with corporate apps installed.

Applies to

Microsoft Intune Android Enterprise work profiles, managed Google Play, current Company Portal versions.

Variant phrasings

Stuck after a factory reset on a personal device

Old work profile remnants can linger; remove the work account fully before retrying.

Waiting screen only on Samsung devices

Check Knox enrollment settings; Samsung-specific policies can add an extra gate.

Why it happens

Android Enterprise enrollment is a handshake between the device, managed Google Play, and Intune. If the admin side is not provisioned, the device waits indefinitely by design.

Edge cases

• Users with multiple work accounts can confuse the setup; use one account.
• Some carriers delay the initial Play connection; retrying later sometimes clears it.
• Document the enrollment profile type used; personally-owned and corporate-owned flows differ.

Provenance

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

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

Thread query: android work profile setup paused: "waiting for your IT admin"

TL;DR: The setup pauses until the admin side is ready: the user needs an Intune license, the enrollment must be approved or configured, and managed Google Play must be connected. Fix the admin side, then have the user retry the setup.

Not specified by the original author.

Fix Google Workspace SCIM provisioning failing for suspended users

TL;DR

Google Workspace skips SCIM provisioning for suspended users by design, and the failure looks like an error. Either unsuspend the user if they should have access, or exclude suspended users from the provisioning scope. Do not treat the skip as a connector bug.

The error

Google Workspace SCIM provisioning: Failed
Error: Cannot provision suspended user to target application

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=google workspace scim provisioning failed suspended user"

Fix it

Step 1: Confirm the user is suspended in Google Admin

Google Admin -> Directory -> Users -> [user], check the status.

Expected: The user shows Suspended.

Step 2: Decide: should this user have app access

Check with the manager or the offboarding ticket whether access should exist.

Expected: You have a clear yes or no for each failing user.

Step 3: If yes, restore the user

Unsuspend the user in Google Admin, then retry provisioning.

Expected: Provisioning succeeds on the next sync.

Step 4: If no, exclude suspended users from scope

Adjust the provisioning scope or app assignment to exclude suspended users.

Expected: The failures stop because suspended users are no longer in scope.

Step 5: Verify the failure list is clean

Re-check the provisioning error report after the next sync.

Expected: No suspended-user failures remain.

When this applies

• Google Workspace SCIM provisioning fails for suspended users
• Offboarded users keep generating provisioning errors
• You are tuning provisioning scope after an offboarding wave

When it doesn't

• Active users fail the same way (that is a different provisioning error)
• You need suspended users to keep app access (change the lifecycle policy)
• The failure mentions a different attribute (check the mapping)

Compatibility

Google Workspace automatic provisioning (SCIM) to third-party apps.

Variant phrasings

google scim suspended user provisioning error

Same behavior. Suspension is a lifecycle state; the provisioner will not create app accounts for it.

workspace provisioning fails offboarded users

Offboarding suspends the Google account but the app assignment lingers. Clean up the assignment.

scim skip suspended users google

Skipping is correct once scope excludes them. Confirm the exclusion is intentional, not a misconfigured filter.

Why it happens

Suspended is a terminal lifecycle state in Google Workspace: the user cannot authenticate, so provisioning an app account for them makes no sense. The SCIM provisioner refuses rather than creating a dead account. The failures are the provisioner telling you the scope still includes people who should not be there.

Edge cases

• Suspended users with licenses still assigned cost money; this error is a good prompt to clean up
• Reactivating a user re-triggers provisioning for every assigned app; expect a burst
• Some apps have their own suspend state; decide whether Google suspension should map to it

If it still fails

• Capture the exact timestamp, the failing username, and the full error from the IdP system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• Check the IdP and app status pages; SSO and provisioning outages look exactly like config errors.
• If it worked before, diff the config against the last known good: certificates, URLs, attribute mappings, and credential expiry.
• Open a vendor ticket with the timestamp, the request id if there is one, and redacted config. Never send secrets or private keys.

Prevention

• Track certificate and credential expiry with alerts, not memory.
• Run a synthetic login per SSO app daily so breakage pages you, not a user.
• Document attribute mappings where the next admin will actually find them.
• Test provisioning with a single user before bulk changes.
• Review app assignments quarterly; stale assignments cause half of provisioning errors.

Provenance

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

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

Thread query: google workspace scim provisioning failed suspended user

TL;DR: Google Workspace skips SCIM provisioning for suspended users by design, and the failure looks like an error. Either unsuspend the user if they should have access, or exclude suspended users from the provisioning scope. Do not treat the skip as a connector bug.

Not specified by the original author.

Fix Google OAuth 403 access denied by admin policy

TL;DR

Access denied by admin policy means the Google Workspace admin has blocked the app, not that your code is wrong. The admin must allow-list the app in the Admin console under API controls. End users cannot fix this themselves.

The error

Google OAuth failed
Error 403: access_denied. The administrator has blocked this app.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=google oauth error 403 access denied admin policy"

Fix it

Step 1: Confirm the block in the Admin console

Google Admin -> Security -> Access and data control -> API controls -> Third-party access.

Expected: The app shows as blocked for the user's org unit.

Step 2: Allow-list the app

Change the app's access setting to trusted for the relevant org units and save.

Expected: The app shows as trusted.

Step 3: Check the OAuth scopes requested

Confirm the scopes the app requests are ones the admin policy permits.

Expected: No requested scope is on the restricted list without approval.

Step 4: Have the user retry the OAuth flow

The user runs the Google OAuth flow again.

Expected: The flow completes instead of showing 403.

Step 5: Document the allow-list requirement

Add the allow-list step to your onboarding docs for Google Workspace customers.

Expected: Future installs include the admin step up front.

When this applies

• Google OAuth fails with 403 access denied by admin policy
• An app works for consumers but not for Workspace users
• You are onboarding Google Workspace customers

When it doesn't

• The error is about unverified app screens (that is the verification flow)
• The admin allowed it and it still fails (check the org unit scoping)
• The error names a specific scope (request a narrower scope)

Compatibility

Google OAuth 2.0 with Google Workspace admin API controls.

Variant phrasings

google oauth blocked by administrator

Same condition. Only a Workspace admin can unblock; the user and the developer cannot.

error 403 access_denied google workspace app

The 403 wrapper is the same admin block. Check third-party access settings first.

google admin blocked third party app oauth

Bulk blocks happen when admins restrict all third-party access. The app needs an explicit trust entry.

Why it happens

Google Workspace admins can block third-party API access org-wide. When they do, every OAuth flow for the blocked app fails with 403 before the user even sees a consent screen. It is a policy decision on the customer's side, not a defect in the app.

Edge cases

• Blocks can be scoped per org unit; the app may work for one team and fail for another
• Restricted scopes need admin approval even for trusted apps; check the scope classification
• After allow-listing, propagation can take several minutes

If it still fails

• Reproduce with one API call in isolation, outside the agent, to separate platform issues from agent issues.
• Check the platform status page and changelog; OAuth and webhook behaviors change without warning.
• Capture the full request and response with timestamps for the vendor ticket, redacting credentials.
• Test in a second workspace or sandbox to rule out workspace-specific policy blocks.
• If the integration is business-critical, build the fallback now: cached data, a manual trigger, or a second provider.

Prevention

• Store OAuth credentials in a secrets manager with rotation reminders.
• Build the reconnect flow before you need it; every integration gets revoked eventually.
• Log token ages so expiring grants are visible ahead of time.
• Keep a sandbox integration for testing config changes.
• Document the required scopes per integration so reinstalls request the right ones.

Provenance

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

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

Thread query: google oauth error 403 access denied admin policy

TL;DR: Access denied by admin policy means the Google Workspace admin has blocked the app, not that your code is wrong. The admin must allow-list the app in the Admin console under API controls. End users cannot fix this themselves.