Diagnose before changing data
Troubleshooting and frequently asked questions
Use the visible state, exact timestamp, role, institute, and failing step to solve common operational problems safely.
All usersSupport staff
Who does thisThe affected user and an authorized support owner
Before you startThe canonical URL and failing workflow step are known
Successful outcomeA documented resolution without unsafe shortcuts or unnecessary data sharing
What this means in plain language
Good troubleshooting narrows a problem using evidence. It does not disable security, rewrite records directly, or repeat destructive actions until something appears to work.
Step-by-step
- Record the page, action, visible message, local time, account role, active institute, and whether the problem is reproducible.
- Check the relevant guide’s prerequisites and “how to know it worked” section.
- Confirm service health: database, queue, scheduler, storage, mail, and canonical URL as applicable.
- Test with a permitted demo or low-privilege account rather than sharing the affected user’s password.
- Collect only redacted logs and identifiers needed to correlate the event.
- Escalate with the installed version, expected outcome, actual outcome, and already-completed checks.
How to know it worked
- The root cause and resolution are recorded.
- Security controls remain enabled.
- No real credential, answer key, private evidence, or raw backup was shared.
- A regression or smoke test proves the workflow works again.
Common mistakes
- Granting Super Admin instead of finding the missing boundary.
- Running destructive database commands on a production schema.
- Sending full logs, database dumps, or screenshots with secrets to support.
If something goes wrong
- Cannot sign in: verify domain, account status, lockout, verification channel, and time.
- Cannot see an exam: verify institute, assignment, eligibility, schedule, and publication.
- Cannot publish: verify marking, moderation, approvals, holds, and permissions.
- Mail not delivered: verify channel settings, queues, provider response, and sender policy.
Privacy and security: Redact names where possible and never include credentials, tokens, full answer content, evidence files, or backups in ordinary support channels.
What to do next
If the problem remains, follow the release checklist and provide the support owner with the minimal redacted evidence.