Understanding the Sonta data model

Most CRMs hand you a fixed set of objects — contacts, companies, deals — and expect your work to bend around them. Sonta works the other way: it gives you a small set of building blocks and lets you shape the model to your operation. Before you configure anything, it helps to see how those blocks fit together, because every later decision — what to track, how records connect, what an agent can act on — follows from this one model. This page walks the whole thing end to end, and each piece links to a page that covers it in depth.

The model in one line

A business holds collections. A collection holds entries. Every entry is described by fields. References connect one collection to another, and stages move an entry through the steps of your process. Everything else — views, automations, agents, your public site — is a way of working with those same records. Hold that sentence in mind; the rest of this page unpacks it.

A business is the container

A business is the top level. Your collections, your team, and your agents all live inside one, and nothing crosses from one business into another — they are fully separate. That separation is what lets one account run several operations side by side without mixing their data. If you have not created one yet, start with Create your first business; the rest of this guide assumes you have one to work in.

Collections and entries: your tables and their rows

Inside a business, a collection is like a table. If you have used a spreadsheet, you already have the mental model: the collection is the sheet, and each row in it is an entry. A Companies collection holds one entry per company; a Deals collection holds one entry per deal. You are not limited to a preset list — you create the collections your work actually needs, and each one is a clean table of its own.

Fields: the typed columns

A field is a column on a collection — the individual piece of information every entry carries. A deal has an amount, a priority, an expected close date; each of those is a field. What matters is that fields are typed: an amount is a number, a close date is a date, a priority is a fixed set of options. The type is what keeps your data clean and lets Sonta do real work with it later — sort by amount, filter by date, group by priority. Adding or changing a field takes minutes and no code, so the model grows as your work does rather than waiting on a release.

References: how collections connect

Real work is not a set of isolated tables — a deal belongs to a company, a booking belongs to a customer. A reference is the field type that makes that connection. On a deal, a Company reference points to one entry in the Companies collection. The key idea: a reference is a link, not a copy. The deal does not store the company's details; it points to the company entry, so when the company's address changes, every deal that references it sees the change at once. This is how a handful of simple collections becomes a connected model of your business.

Stages and pipelines: moving work forward

Most operations have a process — a deal goes from open to won or lost, a request goes from new to resolved. In Sonta, an entry moves through stages, and those stages live in the collection's pipeline. Each stage has a category — open, closed, or archived — so the system knows that Won and Lost are both closed, while the rest are still open. On top of the stages, the pipeline can carry a forecast: how likely an open deal is to close, and which forecast category it falls into. The result is a board you move entries across, plus the numbers that come from where everything sits. Stages and the pipeline each have their own page; here it is enough to know that this is how a collection represents a process, not only a list.

One model, many surfaces

Here is the part that ties it together. Everything above describes records — and records are not locked to one screen. The same deals your team drags across a board are the records an agent reads when it prepares a follow-up, and the same catalog entries behind your operation are what your public site shows to a visitor, writing a new lead or order straight back into the same collection. There is no separate copy for the website and no export for the AI. One model, one set of records, read and written from every side. That is the point of the design: you work with the system of record directly, not next to it. This documentation itself runs on Sonta — the page you are reading is an entry in a collection.

A worked example

Picture a professional-services firm. It keeps three collections: Companies, Contacts, and Deals. A contact references the company they work for; a deal references both the company and the contact leading it. Each deal carries fields — amount, expected close date, priority — and moves through the Deals pipeline: Qualifying, Proposal, Negotiation, then Won or Lost. The team watches the board as a kanban and reads the forecast to see the quarter. An agent, working the same deals, drafts the follow-up when one has sat in Proposal too long. Nothing here is a special integration — it is one model, viewed and acted on in different ways. Swap the firm for a repair shop or a real-estate team and the shapes are the same; only the collections change.

Where to go deeper

From here, each concept has its own page. To see the pieces assembled into a working picture, read how Sonta AI fits together, and for the exact meaning of any term, there is the Sonta AI glossary. When you are ready to build, create your first business and start shaping collections. The individual concepts above — businesses and multi-tenancy, collections and entries, fields, references, and stages and pipelines — are each covered in their own article in this section.