Olympus Docs

Appearance

Data Model & Key Entities ​

Purpose: The core business records and how they relate. Read this to build a mental model of the system before diving into any one app.

Primary users: Anyone building reports or integrations, or trying to understand how a change in one app shows up in another.

The records group into four areas. The lettings funnel in the middle (reservation to deal sheet to tenancy) is the heart of the business.

1. Platform backbone ​

  • Company is an operator (the platform tenant). Each Company has its own isolated database.
  • System is an app in the ecosystem (Olympus, Portal, Everest, reporting). Users are linked to the systems and roles they can use.
  • User is a staff account, linked to its roles and systems.

2. Property & unit ​

  • Property (a development/building) has many Units (apartments).
  • Supporting reference data hangs off these: unit and property types, owners, agents, furniture packs, perks, website channels, points of interest.
  • Replica listings are duplicate portal adverts for a unit (see Everest).

3. The lettings funnel: Reservation → Deal Sheet → Tenancy ​

This is the spine of the business:

  • Reservation holds a unit for an applicant. It carries additional tenants, viewings, moderation, and a payment.
  • Deal Sheet is the detailed record of a customer's tenancy (rent, term, occupiers, deposit). Extra detail lives in deal-sheet meta (key/value), and a deal sheet can link back to an original (for renewals and revisions) and carry contract variations and additional requirements.
  • Tenancy is the live let, linked to its unit and customer, with its notifications and support submissions.
  • Customer is the resident record. A customer has tenancies, subscriptions (direct debits), smart keys and guests, and a linked app login.

4. Finance & ancillary ​

  • Qube records (data, references, unit data, tenant status) hold what has synced to and from the accounting system.
  • Charges, transactions and payments track money owed and paid; subscriptions back the direct-debit collection.
  • Ancillary records include guarantor providers, permitted occupiers, custom fields, smart-lock entities (keys, guests, visitors, public zones), Inventory Hive inspection data, and the traffic-light stage records behind lease progression.

Things that surprise newcomers ​

  • Records are keyed by references, not tidy numeric IDs. Units join by a reference, users by a global_uuid. Integrations should key off these.
  • Some links are polymorphic. Payments, traffic-light statuses and sync statuses attach to more than one kind of parent.
  • Data is split by operator. The central database holds companies, systems and users; each operator's own database holds its properties, units, customers and tenancies. A record only exists within its operator's database.

Where the detail lives ​

Relationships are defined in the app models (apps/*/app/Models) and the shared core (packages/composer/olympus-core). The Statuses & Lifecycles page lists the state values these records move through.