TuffOps Data Model
Almost every TuffOps screen is a view onto a small set of entities. Once you have a mental picture of how they connect, the rest of the product gets a lot easier to navigate.
The five primary entities
| Entity | What it represents |
|---|---|
| Customer | A person or organization you do work for — residential, commercial, or government. |
| Unit | A specific piece of equipment installed at a customer's site (an AC, a chiller, a pump). |
| Quotation | A priced proposal for work, sent to a customer for approval. |
| Work Order | A unit of dispatchable work — a tech visits, does the job, hands it back. |
| Invoice | A billing document for completed work. |
Customers own units. Units appear on work orders. Work orders are usually born from a quotation or a customer request, and end as an invoice once the work is done.
How they connect
Customer ─< Unit ─┬─< WorkOrder ─── Invoice (1:1)
│ ↑
│ ├─ Quotation (1:many on convert)
│ └─ CustomerRequest (1:1 on triage)
│
└─< CustomerRequest
A few rules worth internalizing:
- A unit belongs to exactly one customer at a time. When you sell or transfer the equipment, you move the unit to the new customer (see Units).
- A quotation belongs to one customer and can spawn multiple work orders when it's converted (see Quotation Lifecycle).
- A work order is always tied to a unit (and therefore to that unit's customer). A work order can also stand alone — no quotation, no request — for a quick service call.
- An invoice is created from a single completed work order. It's not a roll-up across jobs; consolidated billing happens in your downstream billing system.
- A customer request is a triage queue item tied to a unit. It either becomes a work order or gets closed as resolved (see Customer Requests).
Supporting entities
The primary five lean on a handful of supporting entities that don't usually have their own top-nav menu:
| Entity | Role |
|---|---|
| Device Type | Category of equipment — Split AC, Chiller, Heat Pump. |
| Manufacturer | The brand — Mitsubishi, Daikin. |
| Device Model | A specific manufacturer's model number — Mitsubishi MSZ-GL09NA. A unit links to a device model, which links to a device type and a manufacturer. |
| Item | Anything billable — labor codes, parts, materials. Items appear as line items on quotations and work orders. |
| Checklist | A reusable template of items a tech must verify on a work order (see Checklists). |
Why this layering matters
The split between Device Model, Unit, and Work Order is the part that surprises people most often. It looks redundant — isn't a unit just a piece of equipment? — but it lets you do things like:
- Attach a checklist to a device model and have every unit of that model auto-attach the checklist when a work order is created.
- Track the warranty clock on the physical unit (when this specific compressor was installed) while still pulling specs from the model.
- Generate a maintenance work order for every unit of a given type when a manufacturer issues a recall.
If you only ever needed one customer, one unit, and one job, none of this would matter. TuffOps is built for the case where you have hundreds of units across dozens of customers, and each one has its own warranty clock, service history, and quirks.
Tenant boundary
Everything above lives inside a single TuffOps tenant. There's no cross-tenant relationship — your customers, your units, your work orders are isolated from every other TuffOps installation. Some integrations (QuickBooks, billing) cross the boundary outwards, but never sideways into another tenant.