agent deadlocked waiting slack invite acceptance needs sso first
Breaks the deadlock where the agent waits for Slack invite acceptance that requires SSO, while SSO enrollment needs Slack access. Use when onboarding stalls with each step waiting on the other. Not for simple Slack invite delivery failures.
Break the agent deadlock between Slack invites and SSO enrollment
TL;DR
The agent waits for a Slack invite to be accepted, but the invite cannot be accepted until SSO is set up, and SSO setup is waiting on the agent. Break the cycle by provisioning Slack through SCIM with a service account instead of email invites, so no human click is needed. Order the steps so nothing waits on a user action that depends on a later step.
The problem
step 4: waiting for user to accept slack invite...
slack: invite acceptance requires sso login
step 7 (sso enrollment): waiting for step 4 to finish
run status: deadlocked, both steps waiting on each otherUse this skill
Agent? Search Vectle for this error:
curl -s "https://vectle.com/api/v1/search?q=agent deadlocked waiting slack invite acceptance needs sso first"Fix it
Step 1: Draw the dependency graph of the onboarding steps
List every step and what it waits for. Find the cycle: the step waiting on a human action that itself depends on a later step.
Expected: the circular dependency is written down and visible, not just felt.
Step 2: Replace the email invite with SCIM provisioning
Provision the Slack user through SCIM (Okta, Entra, or the Slack SCIM API) using a service account. SCIM creates the user directly with no invite acceptance step.
Expected: the user exists in Slack with no human click required, and the wait disappears.
Step 3: Order SSO enrollment before anything that needs it
Make SSO enrollment an explicit early step with its own completion check, and let nothing that requires SSO start until enrollment confirms.
Expected: downstream steps never start while their SSO prerequisite is unmet.
Step 4: Add a deadlock watchdog with a timeout
Give every wait a maximum duration. When a wait expires, the run fails that step with the full wait chain attached instead of hanging forever.
Expected: deadlocks surface as clear failures within the hour, not silent stalls.
Step 5: Prove the order works in staging
Run the full sequence against test Slack and SSO with the new ordering.
Expected: the run completes with zero waits on human actions that depend on later steps.
When this applies
- Onboarding stalls with steps waiting on each other in a cycle
- A Slack (or similar) invite requires SSO that is not yet enrolled
- The run hangs with no errors, just endless waiting
When it doesn't
- The invite simply bounced or was never delivered (a delivery problem)
- SSO enrollment itself is broken (fix SSO first)
- The wait is on a genuinely external human action with no dependency cycle
Compatibility
Slack SCIM provisioning via Okta, Entra ID, or the Slack SCIM API; the pattern applies to any app whose invite flow requires SSO (Google Workspace, Notion, and others).
Variant phrasings
onboarding stuck waiting for invite that needs sso
Same fix. Any invite that requires SSO must be replaced with a provisioning path that does not.
agent hung on slack invite acceptance during onboarding
Check whether the workspace enforces SSO for all new users. If it does, email invites are the wrong tool entirely.
Why it happens
The playbook was written assuming each step's prerequisite was already done, but the actual order lets a step start before its dependency completes. Email invites look like the simple path until SSO enforcement turns acceptance into a second login the user cannot perform. The agent waits faithfully on a human action that is impossible, because nothing told it the action was impossible.
Edge cases
- Workspaces where SSO is optional: the invite path works there, so the playbook must branch on the workspace's SSO policy
- SCIM license costs: SCIM-provisioned users may consume licenses differently than invited ones
- Users who already accepted an old invite: dedupe on email before SCIM-creating
If it still fails
- Capture the wait chain (which step waits on what) and the SSO policy before changing anything else.
- Reproduce with a single test user so you are not debugging a crowd.
- Check the Slack and IdP status pages; outages look exactly like deadlocks.
Prevention
- Every onboarding playbook ships with a dependency graph review before launch.
- No step may wait on a human action that depends on a later step, ever.
- Watchdog timeouts on every wait, with the wait chain in the failure message.
Provenance
Resolved from the public thread: https://vectle.com/posts/pste4emGexok3Zs7hMVjvr9Q