Data Flow Overview

The Two-Layer Architecture

Safe For The Office™ uses two distinct data layers that serve different purposes:

Facilitator Account Data

When a facilitator account is created, the following is written to the database:

• Email address — used for authentication
• Display name — shown in the facilitator portal
• Password hash — scrypt hash only; the original password is never stored
• Account role and status
• Account creation timestamp

This data remains in the database while the account is active. It is not shared with third parties and is not used for advertising.

Data path: Facilitator browser → HTTPS → Application server → PostgreSQL (ca-central-1)

Workshop Room Creation

When a facilitator creates a workshop room, the following is written to the database:

• Room code (e.g. RM-AB3K) — used to identify the session
• Activity type and content pack selection
• Room state (created, lobby, active, completed)
• Timestamps (created, completed)
• Facilitator identifier (links the room to the facilitator account)

Room records do not contain any participant information. They are retained to support facilitator session history.

Data path: Facilitator browser → HTTPS → Application server → PostgreSQL (ca-central-1)

Participant Join Flow

When a participant joins a workshop session:

1. The participant enters a display name and room code in their browser
2. The application server creates an in-memory entry for the participant in the active room's runtime state
3. The participant's display name and a reconnect token are held in server memory only
4. Nothing is written to the database

Participants are anonymous to the platform. No email address, account, or identifier is collected or stored.

Data path: Participant browser → HTTPS → Application server → Server memory only (never reaches the database)

Participant Response Flow

When a participant submits a response during a workshop activity:

1. The response is received by the application server
2. The response is stored in the active room's in-memory runtime state
3. The response is made available to the facilitator's dashboard through the polling model
4. Nothing is written to the database

Participant responses exist only in server memory. They are never written to a database, log file, or any persistent storage.

Data path: Participant browser → HTTPS → Application server → Server memory only (never reaches the database)

Session End Flow

When a workshop session ends — whether the facilitator closes it, it expires due to inactivity, or the server restarts:

1. The in-memory runtime state for the room is cleared
2. All participant names, responses, and session state are permanently gone
3. The room record in the database is updated to reflect the completed state (no participant data is written)
4. An anonymized room lifecycle event is recorded (room code and timestamps only — no participant data)

There is no recovery path for participant data because there is nothing to recover from.

Administrative Activity

When an administrator takes an action on the platform (login, room management, account management):

1. The action is processed by the application server
2. Authorization is re-validated against the database
3. The action is executed
4. An audit log entry is written to the append-only audit log table

The audit log records: the action, the administrator's identity, the target, the result, and a timestamp. It does not contain participant data, passwords, or tokens.

Data path: Admin browser → HTTPS → Application server → PostgreSQL audit log (ca-central-1)

Operational Events

The platform records anonymized room lifecycle events for operational monitoring:

• Room created
• Room opened (moved to lobby)
• Room started (activity began)
• Room completed

These events contain the room code and timestamps only. They do not contain participant names, participant responses, facilitator email addresses, or any identifying information. They are retained for 90 days.

Contact Form Submissions

When a visitor submits the contact form, the name, email address, and message are used only to respond to the enquiry. This information is not used for marketing and is not shared with third parties. Contact form submissions are not currently stored in the platform database — they are handled through the contact channel directly.

Password Reset Flow

When a facilitator requests a password reset:

1. A 32-byte random token is generated
2. Only the SHA-256 hash of the token is stored in the database — the original token value is never persisted
3. The token expires after one hour and is single-use
4. Email delivery for password reset tokens is not yet implemented — this is a known limitation

What Never Enters the Database

Last reviewed: October 2026