Skip to main content

Troubleshooting

The most common Praxis identity issues, organized by what the user sees. Each entry lists the typical cause and the specific fix or check.

Sign-in problems​

"Invalid email or password"​

  • Likely cause: Wrong password, or the account was created via SSO and has no local password.
  • Check: On the standard sign-in screen, enter just the email and watch whether the page redirects to your IdP. If it does, this account is SSO-managed — sign in via the IdP instead of typing a password.
  • Fix: Use Forgot password to reset (password accounts only), or sign in via SSO.

Sign-in succeeds but the app is empty / "no organization"​

  • Likely cause: The user belongs to an organization but no tenant is selected, or the user has not been invited into any tenant.
  • Check: The org/tenant switcher in the shell — does it show Select tenant? Does the Tenants tab in Organization list any tenants the user is a member of?
  • Fix: Pick a tenant, or have an admin invite the user into one with the right role.

"Account not verified" or verification email never arrives​

  • Likely cause: Email delivery (spam folder, blocked by mail filter), or the verification flow is not enabled in your deployment.
  • Check: Spam/quarantine. Some deployments do not require verification — confirm with your administrator.
  • Fix: Re-trigger verification from the sign-in screen if available, or have an admin re-invite the user.

Sign-in works in one browser but not another​

  • Likely cause: Stale session cookie, third-party-cookie blocking (common with embedded SSO callbacks), or browser extensions stripping headers.
  • Fix: Clear cookies for the Praxis domain, disable strict tracking-prevention extensions, or try a private window.

SSO problems​

Sign-in redirects to the IdP and back, then shows an error page​

  • Likely cause: ACS URL or Audience / Entity ID mismatch between the IdP application and the Praxis SSO connection.
  • Check: Open the IdP application's SAML configuration. Confirm:
    • ACS URL / Reply URL = the value Praxis showed on the Configure your IdP panel.
    • Audience / Entity ID = the value Praxis showed.
  • Fix: Update either side to match. ACS URL changes typically also require re-uploading service-provider metadata in some IdPs.

"SSO not configured for your domain"​

  • Likely cause: No SSO connection has the user's email domain in its Email domains list.
  • Check: SSO connections list — does any row show that domain?
  • Fix: Edit (or recreate) the SSO connection and add the domain. Multiple domains are comma- or space-separated.

Wrong role after SSO sign-in​

  • Likely cause: The role-mapping attribute does not match what the IdP actually sends, or the values differ.
  • Check: Use the IdP's SAML tracer / OIDC token inspector to see the actual assertion or token your IdP emits. Compare the attribute name and values to the role mapping in Praxis.
  • Fix: Edit role mapping. Common pitfalls:
    • Microsoft Entra ID sends group object IDs (UUIDs), not display names — use the UUID as the IdP value.
    • Google Workspace sends nothing for groups by default — see IdP setup guides → Google Workspace.
    • Multiple matches: the highest-privilege role wins (owner > admin > member > viewer), so a user mapped to both engineering (member) and platform-admins (admin) becomes admin.
    • Matching is case-insensitive on values, so Admin and admin are equivalent — but the attribute name is case-sensitive.

Every SSO user lands on the default role​

  • Likely cause: The IdP is not actually sending the configured role-mapping attribute, or none of the values match.
  • Check: Inspect the assertion as above. Confirm the custom attribute (for example groups) is in the assertion at all.
  • Fix: Configure the IdP to emit the attribute (see IdP setup guides), or change the role mapping attribute to something the IdP already sends.

"Account already exists" on first SSO sign-in​

  • Likely cause: The user already has a password account with the same email.
  • Fix: The user can sign in with password once and then SSO will work going forward, or an admin can delete the local account before the SSO login. With Enforce SSO enabled for the domain, password sign-in is blocked.

SSO worked yesterday, fails today​

  • Likely cause: IdP signing certificate rotated, or the metadata URL moved. Praxis caches metadata; expired or invalid signatures cause sign-in to fail.
  • Fix: Re-import metadata into the SSO connection. Plan certificate rotations in the IdP and Praxis at the same time.

Enforced SSO locked everyone out​

  • Likely cause: Enforce SSO was enabled for a domain before the SSO connection was actually working end-to-end.
  • Fix: Have an admin whose email is not in any enforced domain sign in and disable Enforce SSO while you debug. As a safety net, keep at least one owner account on a domain that is not SSO-enforced.

Invitation problems​

"Invitation expired" on the accept page​

  • Likely cause: Token expiry (default 7 days) or an admin revoked the invitation.
  • Fix: Have an admin reissue the invite from Invitations.
  • Likely cause: The invite was created in organization scope rather than tenant scope.
  • Check: The Invitations list — does the row show a tenant or only the organization?
  • Fix: Recreate the invite from Tenant settings → Invitations so it is bound to the intended tenant.
  • Likely cause: Their browser still has another Praxis session.
  • Fix: The accept page warns when the signed-in user differs from the invite's email. Sign out, then reopen the link.

API token problems​

401 Unauthorized on API calls​

  • Header malformed: must be Authorization: Bearer <token> exactly. No quotes, no Token prefix.
  • Token revoked or deleted: confirm it is still listed in the tenant's API Tokens tab.
  • Wrong host: make sure you are calling the same Praxis deployment the token was issued in.

403 Forbidden on a specific endpoint​

  • Likely cause: The token's scopes do not include the capability the endpoint requires (for example a pipeline:write call with a read-only token).
  • Fix: Recreate the token with the correct scopes — see Using API tokens → Pick the right scopes.

404 Not Found for a resource you can see in the UI​

  • Likely cause: The token belongs to a different tenant than the resource. Tokens are tenant-scoped.
  • Fix: Issue a token in the right tenant, or set x-ne-tenant-id if the endpoint accepts an explicit context.

Lost the token secret​

  • The secret is shown once. There is no way to retrieve it.
  • Fix: Revoke the old token, create a new one, and roll the secret in your deployment store.

Org / tenant context​

Wrong organization is active​

  • Fix: Use the org/tenant switcher in the shell. If you only see one organization but expect more, you may not be a member of the others — ask an admin to invite you, or check whether you are signed in with the right email.

Page redirects to Identity Management after switching tenants​

  • Expected when you change organization while inside tenant settings — the previous tenant no longer belongs to the new org. Pick a tenant from the new org and reopen.
  • Likely cause: The tenant query parameter does not match a tenant in the current orgId.
  • Fix: Re-copy the URL from the Tenants list, which includes the matching orgId.

Where to look next​

If a problem is not covered here, capture: the exact UI error (or HTTP status), the email domain, the organization and tenant IDs (visible in the deep-link URL of Tenants), and a rough timestamp, then share those with your administrator.