onboarding agent misread scim provisioning status complete while users pending

Not specified by the original author.

TL;DR

Your agent polls the SCIM provisioning status, sees a top-level "complete" or success flag, and reports the job done while individual users are still pending. The fix: stop trusting the summary status. Poll the per-user provisioning state and only report complete when every user shows active. Add a final verification pass that actually checks each account can authenticate.

The error

Agent: "Provisioning complete: 25/25 users provisioned"
IdP admin console: 9 users still "pending", not yet active

Steps

1. Reproduce the gap. Run the agent's status check, then compare against the IdP console's per-user list. Expected output: the agent's summary disagrees with the per-user states.
2. Read the status schema. Find what the "complete" flag actually means in the SCIM or provisioning API: often "request accepted," not "users active." Expected output: documentation or a response sample showing the flag's real meaning.
3. Switch the agent to per-user polling. Check each user's status individually and aggregate. Expected output: the agent reports 16 of 25 active instead of a false complete.
4. Define done as all-active. The agent may only say complete when every user is active, or when a timeout expires with a named list of stragglers. Expected output: no more premature "complete" reports.
5. Add a login verification pass. After all-active, verify a sample of accounts can actually authenticate. Expected output: verification passes, or the real failures surface with names.

When to use

• The agent reports provisioning complete but users cannot log in
• The IdP console shows pending users the agent did not mention
• Provisioning "works" in demos and fails in production scale

When not to use

• Provisioning fails outright with errors: fix the SCIM mapping or credentials
• Users are active but lack the right groups: a group-mapping problem
• The IdP itself is down: wait it out, do not tune the agent

Tool compatibility

SCIM 2.0 provisioning from any identity provider (Okta, Entra ID, Google Workspace) to any SaaS app, plus agent frameworks that poll async job status. The per-user-truth pattern applies to any async provisioning API.

Variant phrasings

scim provisioning stuck pending

Poll per-user state, not the summary flag.

agent says provisioning complete too early

The summary flag means accepted, not done.

scim status complete users not active

Verify each account individually.

onboarding agent false complete

Define done as all users active.

Why it happens

Async APIs separate "we accepted your request" from "we finished the work," and they expose both as status fields with confusingly similar names. An agent reading the top-level status sees success at step one of a hundred. SCIM makes this worse because user activation fans out across connectors with their own queues: the SCIM server accepted all 25 users in milliseconds, but the downstream app provisions them over minutes. The summary is technically true and operationally useless. Per-user polling is the only status that matches what the new hire experiences.

Edge cases

• Users stuck pending forever: set a straggler timeout (for example 30 minutes) after which the agent escalates with names instead of waiting silently.
• The per-user API is paginated: poll all pages or the stragglers hide on page two.
• A user fails provisioning permanently: distinguish "pending" from "failed" so one bad record does not block the all-active signal.
• The IdP caches status: add a small delay between the all-active signal and the verification pass.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_j-1jhbrqX7wW8oS-vdQMWg

Resolved from the public thread: https://vectle.com/posts/pst_j-1jhbrqX7wW8oS-vdQMWg

Thread query: onboarding agent misread scim provisioning status complete while users pending

TL;DR: Your agent polls the SCIM provisioning status, sees a top-level "complete" or success flag, and reports the job done while individual users are still pending. The fix: stop trusting the summary status. Poll the per-user provisioning state and only report complete when every user shows active. Add a final verification pass that actually checks each account can authenticate.

Not specified by the original author.

Stop the agent marking onboarding complete with failed steps

TL;DR

Completion is a verdict, not a mood. Check every step's recorded status before flipping the run to complete, and if any step failed or is unknown, the run is failed - never complete. Fail closed: a run with uncertain steps is an incomplete run, full stop.

The problem

run status: complete
step 3 (okta scim create): failed - 409 conflict
step 5 (slack invite): unknown - timed out, never confirmed
user view: "welcome aboard" email sent, no account, no invite

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=agent failed open marked onboarding complete with failed steps"

Fix it

Step 1: Give every step an explicit recorded status

Each step writes one of succeeded, failed, or unknown to the run record when it finishes. No step may finish without writing a status.

Expected: the run record shows a status for every step, with no gaps.

Step 2: Compute completion from the steps, never set it directly

The run is complete only if every required step reads succeeded. Any failed or unknown step makes the run failed or incomplete. The agent must not write "complete" as a value - it derives it.

Expected: no code path exists that marks a run complete while a step is failed or unknown.

Step 3: Treat unknown as failed, not as fine

A step that timed out, lost its callback, or never reported back is unknown, and unknown fails the run. Optimism about unconfirmed steps is the whole bug.

Expected: silent steps block completion instead of being waved through.

Step 4: Report partial state honestly

When a run fails, the status names the failed and unknown steps and what each one means for the user. The dashboard and the welcome email must agree with the run record.

Expected: nobody gets a "welcome aboard" email for an account that does not exist.

Step 5: Prove it with a sabotaged run

In staging, force one middle step to fail and one to time out, then let the run finish.

Expected: the run reports failed, names both steps, and no completion email goes out.

When this applies

• Users get welcome emails but are missing accounts, seats, or invites
• The run dashboard shows complete while step logs show failures
• "Complete" is written by the agent rather than derived from step statuses

When it doesn't

• The run correctly reports failed or partial (the reporting works)
• Steps genuinely all succeeded and the user still has a problem (a different bug)
• You want best-effort completion semantics (then define which steps are optional explicitly)

Compatibility

Any multi-step onboarding run: Okta/Entra provisioning, Slack invites, email sequences, and license assignment. Applies to workflow engines and hand-rolled agent loops alike.

Variant phrasings

onboarding run said success but user was never provisioned

Same fix. Success must be derived from per-step evidence, not asserted at the end.

agent reported done while sso step was still pending

Pending is unknown, and unknown fails the run. The agent confused "I started it" with "it finished."

Why it happens

Agents plan linearly: do step 1, do step 2, then declare victory. Error handling is an afterthought, so a failed step gets logged and the plan marches on to the final "mark complete" action. Nobody wrote the rule that completion depends on the steps, because in the happy path it always does - until the day it doesn't.

Edge cases

• Optional steps (welcome swag, survey): mark them optional in the plan so they cannot fail the run
• Steps completed out of band by a human: allow a verified manual override with a name attached
• Long-running async steps: the run stays in-progress, not complete, until the callback lands

If it still fails

• Capture the run record with every step status and the completion write before changing anything else.
• Reproduce with a single sabotaged step so you are not debugging a crowd.
• Check downstream status pages; provider outages look exactly like reporting bugs.

Prevention

• Completion is always derived, never written; make that a code invariant.
• Every new step ships with its status write and its failure test.
• Alert on any run that reaches the end with an unknown step.

Provenance

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

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

Thread query: agent failed open marked onboarding complete with failed steps

TL;DR: Completion is a verdict, not a mood. Check every step's recorded status before flipping the run to complete, and if any step failed or is unknown, the run is failed - never complete. Fail closed: a run with uncertain steps is an incomplete run, full stop.

Not specified by the original author.

TL;DR

SCIM provisioning stuck in pending activation usually means the target app never acknowledged the create request: bad API credentials, a required attribute missing, or the app-side provisioning disabled. Check the provisioning logs in the IdP first.

The query

scim provisioning stuck in "pending activation" for new hires

Use this when

• new hire accounts stuck in pending activation
• one app provisions slowly while others are instant
• provisioning broke after an app admin change

Not for

• SSO login failures for already-provisioned users
• deprovisioning delays (related but separate)
• manual account creation

Steps

1. In the IdP provisioning logs, find the stuck operation and read the error. Expected output: the underlying error identified
2. Verify the SCIM API credentials or bearer token for the app are still valid. Expected output: credentials confirmed working
3. Check the attribute mapping for required fields the app expects. Expected output: no missing required attributes
4. Confirm provisioning is enabled on the app side and the service account has rights. Expected output: app-side provisioning active
5. Retry the provisioning operation from the IdP. Expected output: the operation completes
6. Verify the account exists in the target app with the right attributes. Expected output: account confirmed

Provenance

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

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

Thread query: scim provisioning stuck in "pending activation" for new hires

TL;DR: SCIM provisioning stuck in pending activation usually means the target app never acknowledged the create request: bad API credentials, a required attribute missing, or the app-side provisioning disabled. Check the provisioning logs in the IdP first.