WFRLoop Docs
Architecture

Data Model

Three tables — Employees, Processes, Reminders — with field tables and relationships

The brief specifies three tables and adds: "Use whatever database makes sense." Field names and descriptions below are reproduced verbatim from the brief.

Employees

FieldDescription
idUnique identifier
nameFull name
emailEmail address
roleJob title
is_managerBoolean — determines dashboard access
slack_user_idSlack member ID for DMs

Processes

FieldDescription
idUnique identifier
nameProcess/SOP name
sourceWhere SOP lives (Trainual, Notion, Google Docs, etc.)
urlDirect link to the SOP
categoryGrouping label (Sales, Safety, Service, etc.)

Reminders

FieldDescription
idUnique identifier
typecorrection or recognition
employee_idFK to employees
process_idFK to processes
sent_byFK to employees (manager)
noteManager's message
prioritylow / medium / high (corrections only)
statuspending / acknowledged
sent_atTimestamp when created
acknowledged_atTimestamp when acknowledged (null if pending)
employee_feedbackOptional comment from employee on acknowledgement (null if none)

Relationships

  • Reminder belongs_to Employee via employee_id — the recipient of the correction or recognition.
  • Reminder belongs_to Process via process_id — the SOP the reminder is tied to.
  • Reminder belongs_to Employee as sent_by via sent_by — the manager who created the reminder.
  • Employee has_many Reminders — both as recipient (employee_id) and as sender (sent_by).
  • Process has_many Reminders via process_id.

Database choice and indexes

The brief says: "Use whatever database makes sense." It does not prescribe an engine, primary key type, index strategy, or constraints beyond the foreign key relationships and the enum-like fields (type, priority, status) implied by the descriptions. Specific indexes are not specified — the implementation should add them where the derived queries and screen reads warrant, but the brief is silent on the exact set.

On this page