← Back to journey timeline
Elaboration

Data Model & Storage Design

Updated 2025-11-17

Our data model combines a relational database for core entities (tenants, users, campaigns, events) with MongoDB for flexible content such as templates, policies and LMS section content.

This split keeps the critical business logic consistent and queryable, while giving us freedom to evolve rich content without heavy schema changes.

Relational Model

The relational schema focuses on:

  • Multi-tenant structure (tenants, features, users, groups)
  • Campaigns and phishing events
  • Remediation plans tied into the LMS

Below is a summary of the main entities.

Tenant

Represents each organisation using SecureLearning.

  • ID (PK)
  • name – tenant name
  • domain – primary email / web domain

Each tenant is responsible for its own users, groups and campaigns.

User (supertype) and Roles

A single User identity with specialisation by role.

User

  • ID (PK)
  • name
  • email

Subtypes (IS-A):

  • Learner
    • deptNum – department or team identifier
  • Tenant Admin
  • Content Manager
  • Admin

This matches our personas and keeps authentication/identity centralised.

Feature

Represents feature modules that can be toggled per tenant (e.g. LMS, Phishing Engine, Analytics).

  • ID (PK)
  • name
  • tutorial – link or reference to onboarding material

Relates to tenants to define which modules they can use.

Content (supertype) and Templates

Abstract representation of content items stored and reused in the platform.

Content

  • token (PK) – unique identifier
  • path – where the content asset lives (in storage / MongoDB)

Subtypes (IS-A):

  • Email Template
  • Landing Page Template

These templates are used later when composing campaigns and landing pages.

Campaign

Defines a phishing campaign within a tenant.

  • ID (PK)
  • name
  • description

A campaign connects:

  • Target users/groups
  • Email template(s)
  • Remediation plan

Email Event (Email Sending)

Stores each email send/interaction generated by a campaign.

  • ID (PK)
  • profile – context or profile used for personalisation
  • date
  • time
  • args – dynamic arguments used to fill the template
  • emailTemplate (FK) – which Email Template was used

These records support analytics like open/click behaviour and remediation triggers.

Landing Page

Represents a rendered landing page used in phishing simulations.

  • host – domain / host used
  • post – path or endpoint
  • landingPageTemplate (FK) – template from which it was generated

This separation lets us reuse templates while tracking concrete pages per campaign.

Remediation Plan

Defines the immediate feedback and training path when a user fails a simulation.

  • message – feedback shown to the user
  • courseID (FK) – LMS course or module used for remediation

This entity links the Phishing Engine with the LMS.

Non-Relational Model (MongoDB)

MongoDB is used for content where structure may evolve over time and where we mostly care about paths and payloads, not complex joins.

Every document includes a path attribute to keep content organised.

Templates

Email and landing page templates are stored as .html with placeholders that the application replaces at render time.

Paths:

  • /templates/
  • /templates/emails/
  • /templates/pages/

This allows us to version and store template bodies independently from the relational metadata.

Compliance Documents

Policies and compliance-related documents can be stored as .pdf, .md or .txt.

Paths:

  • /compliance/
  • /compliance/policies/

This keeps legal and policy material centralised and easy to retrieve by path.

LMS Section Content

The relational DB handles courses, modules and sections.
The actual content of each section lives in MongoDB, grouped by type.

Paths:

  • /section_content/
  • /section_content/text/
  • /section_content/questions/ – typically JSON files
  • /section_content/quizzes/ – typically JSON files
  • /section_content/rich_content/
    • /section_content/rich_content/videos/
    • /section_content/rich_content/audios/
    • /section_content/rich_content/images/

This design lets us mix text, questions and rich media inside a section without constantly altering relational schemas.

Why a Hybrid Approach?

Using both relational storage and MongoDB gives us:

  • Strong consistency and clear relationships for:
    • Tenants, users, groups
    • Campaigns, events and remediation
  • Flexibility for:
    • HTML templates
    • Rich LMS content
    • Evolving compliance documents

Together, these models support the platform’s core flows: running phishing campaigns, collecting events, and delivering targeted remediation and training.