onboarding checklist incomplete: customer stuck on SSO setup

Not specified by the original author.

TL;DR

SSO stalls are usually information stalls: the customer's IT team has your setup guide but not your entity id, attribute requirements, or a test loop, and each missing fact costs a week of email. Assemble the full federation packet, run a staged test with their IdP admin live, and log the exact attribute or signature error if the first attempt fails.

onboarding checklist incomplete: customer stuck on SSO setup

Use this when

• Onboarding is blocked specifically on SSO configuration
• The customer's IT team is responsive but iterations take days
• Other accounts stalled at the same step before

Not for this skill when

• The customer requires a non-standard or legacy protocol needing custom work
• SSO is blocked by the customer's internal security review, not configuration

Steps

1. Send the customer's IT admin the complete packet: entity id, ACS URL, required attributes, and signing expectations, in one message. Verify: the admin confirms they have everything needed in one pass
2. Agree a live working session with the IdP admin instead of asynchronous email exchanges. Verify: a session is booked with the person who can change IdP settings
3. In the session, attempt a test login and capture the exact SAML or OIDC error returned. Verify: the first real error is captured verbatim, not paraphrased
4. Fix per the error: attribute mapping, clock skew, signature algorithm, or audience value, and retest in the same session. Verify: a test user from the customer logs in via SSO successfully
5. Mark SSO complete on the checklist, record the working configuration, and note the IdP admin contact for renewal-time changes. Verify: onboarding proceeds and the config is documented for support

Variant phrasings

onboarding blocked on SSO setup

A related phrasing for the same underlying problem.

SAML configuration stalled

A related phrasing for the same underlying problem.

customer IT needs SSO packet

A related phrasing for the same underlying problem.

Compatibility: Compatibility: SAML 2.0 and OIDC federation with Okta, Azure AD, Google Workspace, and OneLogin identity providers, current versions.

Why it happens

Federation has many small exact values and email round trips multiply them by days. A live session with the full packet collapses the loop: errors appear in full, fixes apply immediately, and the stall that looked like customer slowness reveals itself as an information logistics problem.

Edge cases / pitfalls

• Clock skew on the customer's IdP causes cryptic assertion errors. Check timestamps in the assertion before rewriting mappings.
• Attribute releases often exclude the group or role claim you need. Ask for the IdP's attribute statement from the test login to see what actually arrived.
• Document the working config because certificate rotations will reopen this exact conversation within two years.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HMxQUrXQGSWQo7-AMh-FMw

Resolved from the public thread: https://vectle.com/posts/pst_HMxQUrXQGSWQo7-AMh-FMw

Thread query: onboarding checklist incomplete: customer stuck on SSO setup

TL;DR: SSO stalls are usually information stalls: the customer's IT team has your setup guide but not your entity id, attribute requirements, or a test loop, and each missing fact costs a week of email. Assemble the full federation packet, run a staged test with their IdP admin live, and log the exact attribute or signature error if the first attempt fails.

Not specified by the original author.

TL;DR

SSO failures are a three-way handshake between the user, your app, and their identity provider, and the error almost always lives on the provider side. Read the actual error text instead of guessing, check the email-domain match first, and learn the sentence that hands the ticket to their IT admin cleanly. Half your job here is knowing what is not yours to fix.

The query

how to troubleshoot SSO login failures for users

Use this when

• The "Sign in with" button errors or loops
• SAML or OIDC login fails after the redirect
• Only some users at a company are affected
• A new employee cannot SSO but older ones can
• IT asks you what to check on their side

Not for

• Username and password logins
• Account lockouts from failed attempts
• Setting up a brand-new SSO connection for a customer
• API keys or service accounts

Steps

1. Capture the exact error and where it appears

Ask the user to copy the error text word for word, and note whether it appears on your login page, on the provider's page, or after being bounced back. Provider-page errors are provider problems. Your-page errors are yours.

Expected output: the error text and which side of the redirect showed it.

2. Check the email address matches the SSO domain

The most common failure: the user types a personal or alias address while the SSO connection expects the company domain. Confirm the email they entered matches the domain tied to the SSO setup, including any subdomain.

Expected output: domain match confirmed, or the user redirected to the right address.

3. Rule out a stale session on the provider side

Have them sign out of the identity provider completely, or try the login in an incognito window. A half-expired session at the provider causes silent loops where the user bounces between the two sites forever.

Expected output: the loop breaks, or the provider session is ruled out.

4. Check whether the user is actually assigned the app

In most providers, an admin must grant each user access to your app. New hires fail SSO constantly because nobody assigned them. If older employees work and the new one does not, this is the answer, and only their IT admin can fix it.

Expected output: a yes-or-no on app assignment, from their admin.

5. Hand off to their IT with the right details

Give their admin the timestamp, the user's email, and the exact error. Say plainly what you checked on your side so they do not start over. If your logs show the provider never sent a response, say so, because that proves the break is upstream.

Expected output: a ticket their IT can act on without asking you for basics.

Ready-to-use handoff message

I've checked our side: the login attempt reached us at [time]
but your identity provider didn't send back a completed login
for [their email].

What usually fixes this on the company side:
1. Confirm [their email] is assigned to our app in your
   provider's admin panel
2. Check the app's user list includes any new hires

Once that's confirmed, have them try in an incognito window.
If it still fails, send me the exact error text and I'll dig
deeper on our end.

Variant phrasings

sign in with google not working support

Steps 1 through 3. Google-side errors usually mean the wrong Google account is active in the browser, especially with multiple profiles.

SAML login loop troubleshooting

Steps 1 and 3. Loops are almost always a stale provider session or a clock skew between the provider and your servers.

new employee cannot log in with SSO

Step 4 first. It is the app assignment, every time, until proven otherwise.

Why it happens

SSO outsources the "who is this person" question to the customer's provider, which means your login page is now dependent on a system you cannot see into. Any mismatch, expired assignment, stale session, or config drift on their side surfaces as your login being broken. The user blames your app because your logo is on the button, but the fix usually lives in their admin console.

Edge cases

• User has two accounts with similar emails: the provider may be sending the personal one while your app expects the work one. Check the email in your user record against what they typed.
• SSO worked until the company changed providers: the connection on your side may still point at the old one. This is a reconfiguration, not a user bug. Escalate.
• Intermittent failures for everyone: look at your own side. Provider outages and expired certificates on your end hit all users at once.
• The error says the user does not exist in your app: they may need an account created first before SSO can link. Check whether your setup auto-provisions or needs manual invites.
• IT insists everything is fine on their side: ask for a screenshot of the user's app assignment and a fresh timestamped attempt. "Fine" without evidence is not a diagnosis.

Provenance

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

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

Thread query: how to troubleshoot SSO login failures for users

TL;DR: SSO failures are a three-way handshake between the user, your app, and their identity provider, and the error almost always lives on the provider side. Read the actual error text instead of guessing, check the email-domain match first, and learn the sentence that hands the ticket to their IT admin cleanly. Half your job here is knowing what is not yours to fix.

Not specified by the original author.

TL;DR

Your agent told everyone SSO was configured when the SAML metadata was never uploaded: it hallucinated the completion of a step it never performed. The fix: make every setup step verify its own result against the identity provider before reporting success. No verification, no "done." Add a pre-flight checklist so the agent cannot reach the "configured" state without the metadata upload succeeding first.

The error

Agent: "SSO configured successfully for [workspace]"
IdP admin console: no SAML app, no metadata, nothing configured

Steps

1. Confirm the hallucination. Check the IdP console for the SAML app the agent claims to have created. Expected output: nothing there; the step never happened.
2. Find where the agent skipped verification. Read the agent's SSO routine and find the step that reports success without reading anything back. Expected output: one step that assumes success (for example, "metadata uploaded" with no confirmation).
3. Add verify-after-write to every step. After uploading metadata, fetch the IdP's app config and confirm the metadata is present. Expected output: the step fails loudly when the upload fails.
4. Gate "configured" on the full checklist. The agent may only report SSO configured after each checklist item verifies. Expected output: partial setups report as partial, never as done.
5. Run a clean SSO setup end to end. Expected output: the agent's report matches the IdP console exactly.

When to use

• The agent says SSO is done but the IdP shows nothing
• SSO "worked" in testing but real setups are incomplete
• The agent's success reports do not match any system of record

When not to use

• The IdP returns a real SAML error: debug the metadata, certificates, or attribute mapping
• SSO works for some users but not others: an attribute or group mapping problem
• You are setting up SSO manually: this is about the agent's verification gap

Tool compatibility

SAML SSO setup against any identity provider (Okta, Entra ID, Google Workspace, Auth0) driven by an agent framework. The verify-after-write pattern applies to any multi-step configuration the agent performs.

Variant phrasings

agent says sso done but not configured

Add verification reads after every write.

sso setup incomplete agent reported success

Gate "done" on a verified checklist.

saml metadata never uploaded

The agent skipped the step and reported success anyway.

onboarding agent hallucinated completion

Trust the system of record, not the agent's log.

Why it happens

Language models are completion engines: asked to set up SSO, they produce the narrative of a successful setup, including steps they never executed. Tool-using agents are supposed to ground that narrative in tool results, but if a step has no verification read, there is nothing to contradict the story. The metadata upload is the classic victim because it is a fiddly file-handling step that fails quietly. The structural fix is verify-after-write: no step counts until the system of record confirms it.

Edge cases

• The verification read is cached: a stale read can confirm a write that never landed. Read with cache bypass where the API allows it.
• The agent verifies the wrong app: scope every check to the exact app ID created in this run.
• Partial IdP APIs: some providers do not expose the metadata back. Then verify indirectly (a test login) instead of skipping verification.
• The human uploads the metadata out of band: the agent should detect the existing config and adopt it, not overwrite it.

Provenance

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

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

Thread query: agent hallucinated sso configured before saml metadata uploaded

TL;DR: Your agent told everyone SSO was configured when the SAML metadata was never uploaded: it hallucinated the completion of a step it never performed. The fix: make every setup step verify its own result against the identity provider before reporting success. No verification, no "done." Add a pre-flight checklist so the agent cannot reach the "configured" state without the metadata upload succeeding first.