> ## Documentation Index
> Fetch the complete documentation index at: https://memberpulseptyltd.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Normalization

> Rules for building a scalable Convex data model (tables vs embedded objects)

The CSV entity registry is a **field inventory + UI spec**. For Convex, we must convert it into a normalized model optimized for:

* predictable queries (lists, filters, reporting)
* multi-tenant isolation
* avoiding large/unbounded embedded arrays

## Table vs embedded

### Prefer a table when

* the collection can grow without bounds (tickets, registrations, enrollments, orders, audit logs, messages)
* you need filtering/sorting/pagination across many items
* the items have their own lifecycle/status

#### Acceptance Criteria

##### Frontend

* [ ] Prefer a table when workflow is implemented in the UI as described.

##### Backend / API

* [ ] Backend behavior supports Prefer a table when as documented.

##### Permissions

* [ ] Access is restricted per the Capabilities matrix on this page (or equivalent role rules).

##### Business Rules

* [ ] All business rules for this feature are enforced.

##### Error Handling

* [ ] Error states return clear messages and appropriate HTTP status codes.

### Embed when

* the list is small and bounded (e.g., a handful of speaker objects)
* you only ever fetch it together with the parent document

#### Acceptance Criteria

##### Frontend

* [ ] Embed when workflow is implemented in the UI as described.

##### Backend / API

* [ ] Backend behavior supports Embed when as documented.

##### Permissions

* [ ] Access is restricted per the Capabilities matrix on this page (or equivalent role rules).

##### Business Rules

* [ ] All business rules for this feature are enforced.

##### Error Handling

* [ ] Error states return clear messages and appropriate HTTP status codes.

## Recommended join tables

Use join tables instead of ORM-style `ManyToMany`:

* `courseCategories` (course ↔ category)
* `memberInterests` (member ↔ interestCategory)
* `eventSponsors` (event ↔ sponsor)

## Key boundaries

* **Auth user** (`users`) is not the same as **member profile** (`memberProfiles`).
* **Registrations/enrollments** are first-class tables (`eventRegistrations`, `courseEnrollments`).
* **Support ticket conversation** should be modeled as a messages table (`supportTicketMessages`).

## Output artifacts

* The schema blueprint is codified in [`convex/schema.ts`](/integrations/backend/convex/schema).

## Features

### Normalization

#### Acceptance Criteria

##### Frontend

* [ ] Developer-facing configuration and usage is documented and internally consistent.

##### Backend / API

* [ ] Convex implementation matches the rules and contracts described on this page.

##### Permissions

* [ ] Tenant scoping and access controls are enforced as described.

##### Business Rules

* [ ] Domain rules/invariants are enforced as described.

##### Error Handling

* [ ] Access violations and validation failures produce deterministic errors.