Purpose: Manage all registered users — view profile and progress, grant or revoke access, impersonate for support, and bulk-delete test accounts.

How to use:

• Search by name or email; sort columns by clicking headers; filter by status if needed.
• Click a row to open the user detail panel (week, language, problems, payment, audit history).
• Use Create User to onboard staff or test accounts; Export CSV for offline review.
• Impersonation mints a 60-minute session — use only when troubleshooting a specific user issue.

Next: Sensitive actions (impersonation, access grants, deletes) appear in Audit Log — check there to confirm an action was recorded.

Purpose: Review new Stripe and iCount orders, failed/refunded states, receipts, refunds, billing changes, and manual follow-up work.

How to use:

• Filter by processor or status, then click an order to open the timeline and action panel.
• Stripe refunds and subscription changes are automated when Stripe has the needed IDs.
• iCount actions are guarded: Diana automates document email, document refund, and recurring billing only when the stored iCount IDs allow it; otherwise the order is marked manual review.

Next: Use Audit Log for broader admin history; order-specific actions are preserved in each order timeline.

Purpose: Track unhandled exceptions, API failures, and other system errors logged by the chatbot, with stack traces and severity.

How to use:

• Triage by severity — Critical first, then Unresolved.
• Open an entry to view stack trace, request context, and the user (if any) affected.
• Mark errors resolved once fixed; add a brief resolution note for future reference.

Next: Recurring errors that affect users may also appear in Warnings (when chat safety rules trip) or Feedback (when users report them) — cross-check before closing.

Purpose: Review safety and policy warnings that the content monitor surfaced during conversations — crisis keywords, off-protocol questions, age issues, and similar flags.

How to use:

• Start with Unreviewed — these need a human decision.
• Open a warning to see the full message context and the rule that fired.
• Mark reviewed once you've taken action (no action needed, contacted user, escalated, etc.).

Next: If a warning reflects a real bug, file it under Errors; if a user complaint, capture in Feedback; if it surfaced via direct user message, reply via Questions.

Purpose: Inbox for bug reports, feature requests, and other free-form feedback users sent to Diana via the chat interface.

How to use:

• Filter by category (bug / feature / other) and status (pending / reviewed / closed).
• Open an item to see the full message and the user who sent it; reply or mark resolved.
• Aim to keep Pending empty — even a brief acknowledgement keeps users engaged.

Next: If feedback is actually a question, move it to Questions; if it points at a system failure, file under Errors.

Purpose: Direct user-to-admin Q&A inbox — questions Diana couldn't or shouldn't answer (clinical edge cases, billing, etc.) routed to a human.

How to use:

• Set the Notification Email so new questions ping you outside the dashboard.
• Filter by Unanswered first; aim for low average response time.
• Open a question to see the full conversation context, then post your reply — the user sees it in their next chat session.

Next: If the question reveals a bug or pattern, log it in Feedback or Errors; if it's a safety concern, check Warnings first.

Purpose: Browse and search every conversation users have had with Diana — for QA, content tuning, and tracking how the bot handles real cases.

How to use:

• Search by user, filter by date, duration, or sentiment to spot outliers.
• Open a conversation to read the full transcript with role indicators (user / Diana / system).
• Use sentiment dips and long sessions as candidates for prompt or content fixes.

Next: If a conversation reveals a recurring bot failure, file it in Errors; a safety concern → Warnings; a content gap → fix in Lessons.

Purpose: Edit the source CBT lesson content (English & Hebrew) that Diana streams to users — text, topic markers, and inline images.

How to use:

• Pick a language and a week; edit text directly. Use <img> tags on their own line to embed diagrams (place files under static/images/lessons/).
• Save changes here, then run scripts/structure_lessons.py from the backend to regenerate structured_lessons.json, and restart the server.
• Respect chunk boundaries — Diana delivers 3 paragraphs per chunk and never splits across topic markers.

Next: Use Chat History to spot-check how live users experience your edits; cross-reference exercises in Exercise Definitions.

Purpose: Configure which video lessons Diana shows to users on video learning mode — week-by-week mapping with EN/HE variants.

How to use:

• Pick a language and edit the video URL / metadata for each week + lesson slot.
• Save changes — they apply immediately to users in video mode.
• Empty slots = no video for that lesson (users in video mode will be told to switch back to chat).

Next: Users can switch their preference between chat and video at any time; check Users to see who is on video mode.

Purpose: Edit the 10-question symptom survey users complete on intake, weekly, and at course completion (scored 0–40, lower is better).

How to use:

• Pick a language; edit each question and its 5 response options (0–4 scoring).
• Save — changes affect new submissions only; historical responses remain anchored to the version they were taken under.
• Keep EN/HE in sync — users see whichever matches their detected language.

Next: Per-user scores are visible in Users; aggregate trends in the Overview KPIs.

Purpose: Define the practice exercises Diana guides users through each week — title, instructions, prompts, and example wording.

How to use:

• Pick a language and a week; edit each exercise definition.
• Be precise: Diana's prompt builder reads these directly when guiding users.
• Reminder: during exposure weeks (6+) never include relaxation, breathing, or cognitive-challenging language — exposure goal is to tolerate distress.

Next: Edits flow through to the user-facing Exercises screen and the chat practice flow; cross-check related Lessons content stays consistent.

Purpose: Read-only HIPAA 164.312(b) audit trail of administrative actions — logins, impersonations, access grants, deletes, content edits, and configuration changes.

How to use:

• Filter by event type or actor to narrow the timeline.
• Open an entry to see the full payload (before / after, IP, user agent).
• Use this page to verify any sensitive action was recorded — required during compliance reviews.

Note: Entries here cannot be edited or deleted; this is the system's source of truth for "who did what, when".

Purpose: Configure system-level settings: dashboard branding, Text-to-Speech, email provider, HIPAA / SOC 2 controls, API keys, and webhooks.

How to use:

• Each card below is independently collapsible — click a card header to expand it.
• Changes save per card via the card's own Save button — there is no global "save all".
• Treat API keys as secrets; the audit log records every read and update.

Note: SECRET_KEY and ENCRYPTION_KEY are shared with the marketing engine — never rotate them on only one app or you will break cross-app login and PHI decryption.