The PropLink data model

PropLink's data model is built around two things: the property hierarchy (estate → site → building → floor → space → unit) and the people hierarchy (organisation → contact / vendor / user). Everything else hangs off those.

This page is the canonical reference. If you have ever asked "where does X live?", the answer is somewhere on this page.

The property hierarchy

Organisation (your firm)
└── Estate (optional grouping of sites)
    └── Site (one property)
        ├── Building (a physical structure on the site)
        │   └── Floor (one level of the building)
        │       └── Space (a room or area on the floor)
        ├── Unit (a flat, house, commercial unit or parking bay)
        └── Workspace records (one per active product)
            ├── BmSite  (Block Management workspace)
            ├── FmSite  (Facilities Management workspace)
            ├── LtSite  (Lettings workspace)
            └── HrbSite (Building Safety workspace)

Estates

An estate is a logical grouping of sites under one freeholder, one management contract or one development. Estates are optional, a single-block organisation may not have any. See Estates.

Sites

A site is one property record. It has an address, a postcode and one or more product modules associated with it. Every site belongs to exactly one organisation. See Sites.

Buildings, floors, spaces

A site can have one or more buildings. Each building has one or more floors. Each floor can have spaces, hallways, plant rooms, gardens, car park bays. This hierarchy is most useful in Facilities Management for asset tracking and in Building Safety for the golden thread. See Buildings, floors and spaces.

Units

A unit is a rentable or leasable space inside a site: a flat, a house, a commercial unit, a parking bay. Units carry a reference (Flat 1), an optional UPRN, a floor number and a square-metre figure. Leases, demands, statements and arrears all attach to units. See Units.

Product workspaces

Each active product on a site has its own workspace record holding product-specific fields. The workspaces sit alongside the site without duplicating its core data. A site can have:

• BmSite: Block Management fields like the freeholder reference and Section 20 settings.
• FmSite: Facilities Management fields like the FM contract reference.
• LtSite: Lettings fields.
• HrbSite: Building Safety fields like the regulator reference and the registration date.

The people hierarchy

Organisation
├── Users (PropLink staff who sign in)
├── Contacts (people in the wider directory)
│   ├── Leaseholders / tenants (attached to units)
│   ├── Freeholders (attached to estates and sites)
│   ├── Directors (of RMCs and freeholder companies)
│   ├── Site managers (often also users)
│   └── Other (next-of-kin, solicitors, agents)
├── Companies (legal entities, managing agents, freeholders, RMCs)
└── Vendors (suppliers and contractors)

Contacts and users

A user is someone who signs in to PropLink. A contact is anyone in your address book, most are not users, but some are both (a site manager who is also a contact for their assigned sites).

Vendors

A vendor is a supplier or contractor. Vendors have service categories, contact details, insurance records and certifications. Work orders are dispatched to vendors. Bills (creditor invoices) are received from vendors.

The financial spine

Organisation
├── Chart of accounts (ledger accounts)
├── Tax rates
├── Currencies
├── Bank accounts
├── Lease schedules (Block Management)
├── Invoices (debtor + creditor)
├── Payments (debtor receipts + creditor payments)
├── Credit notes
├── Overpayments
├── Journals (manual + automatic)
├── Budgets
└── Audit log

Every financial record is double-entry. Every record posts to two or more ledger accounts so the ledger balances at all times. This is why you cannot reconfigure or delete a ledger account that has any posted transactions.

The operational spine

Organisation
├── Maintenance events (planned and recurring)
├── Issues (problems reported on sites)
├── Work orders (work assigned to contractors)
├── Tickets (requests and complaints)
├── Service agreements (contracts with vendors)
├── Compliance matrix (regulatory schedule)
├── Files / documents
└── Audit log

Issues, tickets and work orders are linked. An issue can be promoted into a work order. Tickets can reference issues, work orders, sites and units. See Tickets vs issues vs work orders.

Identifiers

Every record has two identifiers:

• A UUID: the canonical reference used by the API and across joins. UUIDs are immutable.
• A human reference that you can choose: for example GC-001 for a site, INV-2026-Q1-0042 for an invoice. Human references can be edited (though most are auto-numbered).