docs: add SSO provider switching guidance to SSO overview

[decimal-pr-bot]

Summary of Changes

• Added "Switching SSO providers" section to data/docs/manage/administrator-guide/sso/overview.mdx
• Documents: one SSO config per domain constraint, password credential prerequisite before deletion, user impact during migration window
• Updated frontmatter date

Reasoning

• Users attempting to switch SSO providers (e.g., Google to Okta) discover they can't add a new config while one exists, with no docs explaining the constraint
• SSO-only admins risk locking themselves out when deleting SSO config without first setting up password credentials
• No guidance on the impact to other users during the migration window between providers

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
signoz-web	Ready	Preview, Comment	Apr 9, 2026 0:06am

[github-actions]

Claude finished @decimal-pr-bot[bot]'s task in 2m 3s —— View job

---

Review: docs — SSO provider switching guidance

• Gather context and read changed files
• Run docs review skill (JTBD rubric + authoring standards)
• Post review summary

---

Findings

P2 — UI path inconsistency (overview.mdx:49): Step 1 uses Settings → Workspace Settings → Members, but every other SSO doc in this directory uses Settings → Organization Settings → Members & SSO (see sso-google.mdx:120, oidc-keycloak.mdx:117, saml-keycloak.mdx:107). Please verify the actual UI label and align with the existing convention. Inline comment →

P2 — Structural mismatch (overview.mdx:47-51): The intro reads "Before deleting the existing configuration:" but step 3 is the deletion. This mixes prerequisites (steps 1-2) with the action (step 3), which can confuse admins performing a high-stakes operation. Separate the prerequisites from the action step. Inline comment →

Personas and fit

• Primary persona: SigNoz admin migrating between SSO identity providers.
• Fit: Good — addresses a real gap where admins can lock themselves out. The constraint (one SSO config per domain) and the password-credential safety net are clearly stated.

JTBD coverage

Check	Status
Primary job obvious	Pass — switching SSO providers
Happy path followable	Needs fix — step list structure mixes prereqs and action
Steps concrete and unambiguous	Needs fix — UI path should be verified
Critical prerequisites called out	Pass — password credential setup is front and center
User impact documented	Pass — migration window impact noted

Checklist coverage (docs-authoring.md)

• Frontmatter: all required keys present, doc_type: explanation appropriate for an overview page.
• Formatting: step 1 uses inline code for the UI path while the rest of the page (lines 30-34) and all sibling SSO docs use bold for UI paths. Should align to bold for consistency.
• No new links, images, redirects, or sidebar changes needed — this is an additive section to an existing page.

Open questions

• Is Generate Reset Password Token the exact button label in the SigNoz UI? Incorrect labels send admins on a hunt during a stressful operation.
• Does the password login fallback (?password=Y) work when SSO enforcement is toggled on? If not, the steps should mention disabling enforcement first.

Onboarding label

Onboarding label: skipped — edit to an existing explanation page; not a new ingestion guide.