Common Login & Access Issues

This guide walks through the most common login and access problems reported for SAVHN, with steps to diagnose and resolve each one.

"I can't log in at all"

Symptom: "Invalid email or password"

1. Confirm you're using the email address your organization invited you with — a personal email won't work if you were invited on a work address, or vice versa.
2. Use Forgot password to reset rather than guessing repeatedly; repeated failed attempts may trigger a temporary lockout as a security measure (see below).
3. If your organization uses single sign-on (SSO), you may not have a platform password at all — check with your admin whether you should be authenticating through your identity provider instead of the email/password form.

Symptom: Account temporarily locked after failed attempts

SAVHN applies a short lockout after repeated failed login attempts to protect against credential-stuffing. Wait for the lockout window to pass, or contact your Org Admin, who can see the failed-attempt pattern in the audit log and unlock the account if the lockout resulted from a legitimate mistake rather than an attack.

Symptom: Invitation link expired or already used

Invitation links are single-use and time-limited. If yours has expired:

1. Ask your Org Admin to resend the invitation from Admin Console → Users.
2. If you already set a password previously and are simply trying to log in again, use the normal login form, not the original invite link — invite links are only for first-time activation.

"I logged in but can't see a module I need"

This is a permissions issue, not a login issue — the two are diagnosed differently. Work through these in order:

1. Is the module enabled for your organization at all? Ask your Org Admin to check Admin Console → Modules. If it's not enabled, no role change will make it appear — see Troubleshooting Module & Integration Issues.
2. Does your role include it? Ask your admin to check your assigned role under Admin Console → Roles & Permissions, or your individual overrides under Admin Console → Users → [you] → Permissions.
3. Is there a record-level restriction rather than a module-level one? Some modules are visible but scoped — for example, a Manager role sees Projects but only projects they're a member of. If the module itself is visible but a specific record isn't, this is expected scoping, not a bug.

"I get a 403 or 'access denied' clicking into a specific record"

This typically means the module is visible to you but the specific record's permission scope excludes you — for example, a Ticket assigned to a different team, or an HRMS record belonging to an employee outside your reporting line. Confirm with your admin whether you're expected to have access to that specific record; if so, they can grant it via a user-level permission override.

"My session keeps logging me out"

• Sessions expire after a period of inactivity as a security measure; this is expected behavior, not a bug, and the timeout duration is generally not user-configurable.
• If logouts happen unexpectedly during active use, check whether you have the same account logged in from multiple devices/browsers in a way that could be invalidating sessions, and check your network connection stability — intermittent connectivity can present as unexpected logouts.
• Persistent, frequent unexpected logouts during active use are unusual and worth reporting to your admin, who can check the audit log for a pattern (e.g. repeated forced token expiry) that would help diagnose it.

"I'm building an integration and get 401/403 from the API"

Response	Likely cause	Fix
401 Unauthorized	Missing, malformed, or expired bearer token	Re-authenticate via POST /api/auth/login or regenerate the API key; confirm the Authorization: Bearer <token> header is present and correctly formatted
403 Forbidden	Token is valid but the identity's role lacks permission for that action	Check the role/permissions of the identity the token belongs to; adjust via Role Management or use a differently-scoped credential
404 Not Found on a domain that should exist	Module not enabled for the organization	Confirm the relevant module is enabled in the Marketplace
429 Too Many Requests	Rate limit exceeded	Back off per the Retry-After header; consider switching from polling to webhooks

See Developer Portal Overview for the full authentication flow and API Reference for status code meanings.

"I have SSO configured but it's not working"

1. Confirm with your admin that your specific email domain is covered by the organization's SSO configuration — some organizations enable SSO only for certain domains during a phased rollout.
2. If SSO login redirects but then fails to complete, this is most often an identity provider-side configuration issue (e.g. a group/role mapping that doesn't resolve to a valid SAVHN role) rather than a SAVHN account problem — your admin will need to check the SSO configuration in the Admin Console alongside your identity provider's own logs.
3. If you previously had a password-based account on the same email before SSO was enabled, ask your admin whether that account was migrated or should be deactivated in favor of the SSO identity, to avoid confusion about which login method to use.

"A colleague with the same role as me sees more/less than I do"

This is almost always a user-level permission override, not a role difference, since two users on an identical role should otherwise see identical navigation:

1. Ask your admin to compare your Admin Console → Users → [user] → Permissions override list against your colleague's — a difference here explains the discrepancy directly.
2. If no override exists on either account, confirm you're actually both assigned the exact same role and not two similarly-named roles with different underlying permissions (this happens when a role was duplicated and diverged over time).
3. Rule out record-level scoping differences — for example, if the disparity is about which specific records are visible rather than which modules appear, the cause is likely different department or reporting-line assignments rather than a role or override issue at all.

Diagnostic checklist to run before escalating

• Confirm the exact error message or status code — "it doesn't work" is much harder to diagnose than "403 on GET /api/hrms/employees."
• Confirm whether the issue is reproducible for you specifically or affects your whole team — this quickly separates a permissions/account issue from a module/platform issue.
• Check whether the module in question is enabled at the org level.
• Check your role and any user-level permission overrides.
• For API issues, confirm the token hasn't expired and was issued for an identity with the permission you're expecting.
• Check the Admin Console audit log for related events (recent role changes, lockouts) around the time the issue started.

If these steps don't resolve it, escalate to your Org Admin with the specific error and steps to reproduce; if the issue appears to be platform-wide rather than organization-specific, your admin can escalate further to SAVHN support.