Skip to content

Data Model

Verified against source (7)

  • application/GenericObject.cs
  • Interfaces/ITemplate.cs
  • Config/Abstract.config
  • Tables/Process.sql
  • Tables/Contact.sql
  • Tables/Attachment.sql
  • Stored Procedures/pHistoryTablePurge.sql

QBO stores everything as records: contacts, organizations, processes (cases), documents, messages, workflows, tasks, ledgers. A handful of patterns repeat across every record type, so once you know them, every part of QBO behaves the way you expect.

The building blocks of QBO — documents, messages, workflows, tasks, ledgers, scores, and processes — are generic: each one can attach to any other record. A document can belong to a process, a contact, or another document; a message can belong to a ledger. The record it belongs to is its parent.

Parents matter because security, reporting, and retention follow them. Partners who can see a process can see the documents and messages on it, and nothing else.

Most records are made from a template: the definition of a kind of process, workflow, document, task, or message. The template decides what the record can attach to, how many of them a parent may have, and how they behave. Change the template and every new record follows it.

Rather than repeat the same fields everywhere, QBO builds some record types on top of others:

  • Organizations and people are contacts. Name, address, and location live on the contact, with its phone numbers and email addresses attached to it; an organization or a user adds what is specific to it.
  • Specialized processes are processes. Industry modules add process types with their own fields, such as a litigation matter, an eviction, or a title order. Each one still gets everything a process (case) has: opened and closed dates, status, assignment to a team or partner, a workflow, and a cost ledger. Reports across all processes include every specialized type.

Whenever a record changes, QBO keeps a copy of the previous version: what it said, who changed it, and when. Status changes are also logged separately, so you can see how long a record spent in each status. Templates keep the same history, so you can see who changed a workflow or a document template.

This history is an audit trail, kept for a period your retention policy sets. Choose Power user to read a record’s history and see how retention works, or Developer for the API.