Access troubleshooting

Do not “fix” access by sharing accounts, changing a role from an unverified request, or exposing a reset link. Start with the exact route and user-visible message.

1. Confirm the intended account address through the approved identity process.
2. Ask the person to retry sign-in or password reset through /auth or /reset-password.
3. Determine whether the issue is authentication, a missing role, a missing sponsor relationship, speaker ownership, or an expected feature gate.
4. An authorized admin reviews the minimal relevant role/membership record and makes only the approved correction.
5. Have the person retry in a fresh session; document the result without including credentials.

Escalate redirect loops, role escalation requests, cross-organization access, or any suspicion that a route guard and underlying data access disagree.

Purpose and scope

Use this runbook for an authorized person who cannot sign in, reset a password, or reach an expected attendee, sponsor, speaker, or admin surface. It does not authorize a role change, a password disclosure, or access through an alternate account.

Prerequisites and role

The support owner needs an authorized admin account and an approved identity-verification channel. Record only the request, time, route, and outcome. The User Manager has account and invitation controls; it also exposes one-time credentials, so restrict screen sharing and never copy them into chat or tickets.

Decision path

1. Start at the reported route. /auth and /reset-password are self-service entry points; protected routes are defined in src/App.tsx.
2. Establish whether the person can authenticate but lacks a route, or cannot authenticate at all. A redirect or missing page alone does not identify the cause.
3. For a signed-in user, have an authorized admin inspect only the relevant relationship: admin role, sponsor membership, or speaker ownership. Sponsor routes require sponsor access; speaker routes require the linked speaker relationship.
4. If an account invitation is pending, use the authorized invitation workflow. Do not resend an email without message-specific authorization.
5. If an authorized administrator must issue a temporary credential through User Manager, share it once through a trusted channel and require a password change. The UI states that this invalidates the existing password.

Expected result and evidence

The person reaches only the intended route in a new session. Record the role/relationship correction and the retest result, not credentials. This is application-level evidence; confirm live behavior in the target environment rather than inferring it from source.

Failures, recovery, and escalation

For browser/camera/cache issues, retry in a fresh private session after preserving the error text. For unexpected access to another organization, stop investigation in the affected account and use incident response. For role disagreements or repeated reset failures, escalate to Product/Engineering with the route, time, and sanitized error.