Data Model

The same screens for every record type

Each record type in QBO comes with the same set of screens, so a new module is familiar the first time you open it.

Screen	What it shows
Home	All records of the type: search, filter, and act on them.
Summary	One record with its parent and its children. A main panel shows the record itself; a tab shows its parent; panels below list its documents, messages, workflows, processes, and other children.
Select	The fields of one record, read-only.
Edit	The same fields, editable. Without a record, it creates a new one.
Search	A list of records matching your criteria.
Dashboard	Totals for the type, such as a chart or pivot table.

Where is this data coming from?

On a summary page, most of what you see comes from the record itself, and each panel lists child records attached to it. Some values come from the parent instead: a process summary may show an address that belongs to the property or contact the process is attached to.

To see every value behind a summary page and which record it belongs to, ask for the data instead of the screen. Add Output=Xml (or Output=Json) to the summary request:

GET /api/contact/summary?ID=1001&Output=Xml

The result groups the values by the record they come from (for example, ContactItem for the contact’s own fields), so you can see which record each field lives on before you build a report, a rule, or a document template on it.

Reading a record’s history

QBO keeps a copy of the previous version of a record every time it changes. Saving a record without changing anything doesn’t add a version.

To see	Use	Permission
Every earlier version of a record, newest first, with who changed it and when	/api/{module}/historylist?ID={id}	{Module}HistoryList
One earlier version, in the record’s normal layout	/api/{module}/selectversion?VersionID={versionId}	{Module}SelectVersion
Each status change: old status, new status, who, and when	/api/{module}/statushistorylist?ID={id}	{Module}StatusHistoryList

For example, /api/process/historylist?ID=5012 lists every earlier version of process 5012. Some screens offer the same list as a history icon next to a record.

History is for reviewing one record at a time. Don’t build reports on it; report on the records themselves.

History retention

History grows with every change, so it is purged on a schedule. Every purge policy is configurable per installation: how long each kind of data is kept, and how often the purge runs.

Data	Standard retention
Change history (earlier versions)	90 days after the change
Logs	90 days
Records with no parent, such as a top-level process	7 years after the last activity on the record or anything under it
Documents, messages, workflows, and other generic records	Until their parent is purged
Templates	As long as any record made from them is kept

Status-change history is purged on the same schedule as change history. Template history is kept by default, which is the recommended setting for most installations: it records who changed a workflow, document template, or other definition, and when. It can be purged too if your retention policy calls for it.

This is the standard policy unless your contract specifies otherwise. If an audit or regulation requires a longer (or shorter) audit trail, ask for the retention to be changed.