Stood CRM Data Model

Overview

Stood is a Customer Relationship Management (CRM) system built on Firebase Firestore. The data model is designed around core business entities: Accounts, Contacts, Deals, Activities, Posts, Users, and Teams. All data is stored as JSON documents in Firestore collections with consistent field naming and structure.

Firestore Collections

1. accounts

Purpose: Companies or organizations

Document Structure:

{
  "name": "string",
  "location": "string | null",
  "website": "string | null", 
  "description": "string",
  "parent": "string | null",
  "archived": "boolean"
}

Fields:

• name (string): Company name

• location (string|null): Geographic location

• website (string|null): Company website URL

• description (string): Business description

• parent (string|null): Parent account document ID for hierarchical relationships

• archived (boolean): Soft delete flag, defaults to false

2. contacts

Purpose: Individual people associated with accounts

Document Structure:

{
  "firstName": "string | null",
  "lastName": "string | null",
  "account": "string",
  "email": "string | null",
  "phone": "string | null",
  "role": "string | null",
  "location": "string | null",
  "archived": "boolean",
  "team": "string",
  "activations": ["string"]
}

Fields:

• firstName (string|null): First name

• lastName (string|null): Last name

• account (string): Associated account document ID

• email (string|null): Email address

• phone (string|null): Phone number

• role (string|null): Job title/role

• location (string|null): Geographic location

• archived (boolean): Soft delete flag, defaults to false

• team (string): Associated team document ID

• activations (array of strings): List of activation events

3. deals

Purpose: Sales opportunities and transactions

Document Structure:

{
  "name": "string",
  "account": "string",
  "amount": "number",
  "stage": "string",
  "description": "string",
  "solution": "string | null",
  "creationDate": "timestamp",
  "closingDate": "timestamp",
  "relatedContacts": ["string"],
  "tags": ["string"],
  "team": "string",
  "owner": "string | null",
  "parent": "string | null"
}

Fields:

• name (string): Deal name

• account (string): Associated account document ID

• amount (number): Deal value in cents/currency units

• stage (string): Current sales stage ("s0", "s1", "s2", "s3", "s4")

• description (string): Deal description

• solution (string|null): Proposed solution

• creationDate (timestamp): Deal creation timestamp

• closingDate (timestamp): Expected close date

• relatedContacts (array of strings): Associated contact document IDs

• tags (array of strings): Deal categorization tags

• team (string): Owning team document ID

• owner (string|null): Deal owner user document ID

• parent (string|null): Parent deal document ID for hierarchical deals

4. activities

Purpose: Tasks and actions related to deals/contacts

Document Structure:

{
  "todo": "string",
  "account": "string",
  "contact": "string",
  "deal": "string",
  "comments": "string",
  "date": "timestamp",
  "status": "string",
  "owner": "string",
  "team": "string"
}

Fields:

• todo (string): Activity description

• account (string): Associated account document ID

• contact (string): Associated contact document ID

• deal (string): Associated deal document ID

• comments (string): Activity notes

• date (timestamp): Scheduled/actual date

• status (string): Current status ("todo", "done", "cancelled")

• owner (string): Activity owner user document ID

• team (string): Associated team document ID

5. posts

Purpose: Communication threads within deals

Document Structure:

{
  "content": "string",
  "deal": "string",
  "sentAt": "timestamp",
  "comments": ["object"],
  "author": "string",
  "generated": "boolean",
  "meta": "object | null"
}

Fields:

• content (string): Post content

• deal (string): Associated deal document ID

• sentAt (timestamp): Post timestamp

• comments (array of objects): Nested comments structure

• author (string): Post author user document ID

• generated (boolean): AI-generated content flag, defaults to false

• meta (object|null): Additional metadata

6. users

Purpose: System users and their preferences

Document Structure:

{
  "firstname": "string",
  "lastname": "string",
  "starredDeals": ["string"],
  "teams": ["string"],
  "admin": "boolean",
  "avatarBytes": "string | null",
  "email": "string | null"
}

Fields:

• firstname (string): First name

• lastname (string): Last name

• starredDeals (array of strings): Bookmarked deal document IDs

• teams (array of strings): Associated team document IDs

• admin (boolean): Administrative privileges, defaults to false

• avatarBytes (string|null): Base64 encoded avatar image

• email (string|null): Email address

Note: Document ID matches Firebase Auth UID

7. teams

Purpose: Organizational units with specific roles

Document Structure:

{
  "name": "string",
  "authorizedEmails": ["string"],
  "apiKey": "string | null",
  "category": "string",
  "nextTeam": "string | null"
}

Fields:

• name (string): Team name

• authorizedEmails (array of strings): Allowed email addresses

• apiKey (string|null): API access key

• category (string): Team type ("pre_sales", "sales", "after_sales")

• nextTeam (string|null): Next team document ID in workflow (for s3 stage transitions)

Field Value Enumerations

Activity Status Values

• "todo": Pending activity

• "done": Completed activity

• "cancelled": Cancelled activity

Deal Stage Values

• "s0": Initial stage

• "s1": Qualification stage

• "s2": Proposal stage

• "s3": Negotiation stage

• "s4": Closed stage

Team Category Values

• "pre_sales": Pre-sales activities

• "sales": Sales activities

• "after_sales": Post-sales support

Document Relationships

teams (1) ──→ (N) users
teams (1) ──→ (N) deals
teams (1) ──→ (N) contacts
teams (1) ──→ (N) activities

accounts (1) ──→ (N) contacts
accounts (1) ──→ (N) deals
accounts (1) ──→ (N) activities

deals (1) ──→ (N) activities
deals (1) ──→ (N) posts
deals (1) ──→ (N) contacts (via relatedContacts array)

users (1) ──→ (N) deals (via owner field)
users (1) ──→ (N) activities (via owner field)
users (1) ──→ (N) posts (via author field)

deals (1) ──→ (1) deals (via parent field - hierarchical)
accounts (1) ──→ (1) accounts (via parent field - hierarchical)

Firestore Storage Patterns

Data Types

• Timestamps: Stored as Firestore Timestamp objects

• References: Related documents stored as document ID strings

• Arrays: Stored as JSON arrays

• Objects: Stored as JSON objects

• Soft Deletes: archived boolean flags instead of hard deletes

Multi-Tenant Architecture

• All documents include team field for data isolation

• User ownership tracked via owner fields

• Firebase Auth UID matches user document ID

• Team-based access control for all collections

Data Access Patterns

Query Patterns

1. User Authentication: Firebase Auth → user document lookup

2. Team Assignment: User belongs to teams → data access scoped by team

3. Document Creation: New documents inherit team context

4. Cross-References: Related documents linked via document IDs

Performance Considerations

• Team-based data partitioning for scalability

• Soft deletes preserve referential integrity

• Document ID references avoid expensive joins

• Array fields for many-to-many relationships

Extensibility Features

• meta object fields for custom data

• tags arrays for flexible categorization

• Hierarchical relationships via parent fields

• Team workflow transitions via nextTeam field

Best Practices

1. Always set team context when creating documents

2. Use document ID references to maintain relationships

3. Implement soft deletes with archived flags

4. Validate enum values against allowed string values

5. Maintain referential integrity through document ID relationships

6. Use consistent field naming across collections

7. Handle null values gracefully in document structure

Contact - Stood CRM support & integration