Collections and entries
A collection is a container for one kind of thing — customers, orders, properties — and an entry is a single one of them. If a spreadsheet helps: the collection is the sheet, an entry is a row. You create the collections your work needs rather than fitting into a fixed set, and everything else in Sonta is built on top of them.
Two words carry most of the weight in Sonta. A collection holds one kind of thing. An entry is one of them. A Customers collection holds one entry per customer; an Orders collection holds one entry per order. Nearly everything else — views, automations, reports, what your site shows — is a way of working with entries in collections.
The familiar comparison
If you have used a spreadsheet, you already have most of this: the collection is the sheet, an entry is a row, and the fields are the columns. That comparison is worth keeping because it is accurate about shape — and worth outgrowing, because a collection does things a sheet cannot: its columns have types, its rows link to rows in other collections, and its entries move through stages.
What makes a good collection
The question that decides a good collection is simple: what does one entry represent? Answer it in a single sentence — "one entry is one repair job", "one entry is one property listing" — and the rest follows. The fields become obvious, because they are the things you know about that one thing.
When that sentence is hard to say, the collection is usually trying to be two things at once. "One entry is a customer, or sometimes an enquiry" is a sign you need two collections with a link between them rather than one collection with half-empty fields. It is easier to split them at the start than to unpick them once there is real data.
You create the collections you need
Sonta does not hand you a fixed set of objects to work within. A new business starts with a sensible base — companies, contacts, deals — but that is a starting point, not a boundary. If your work runs on work orders, shipments, matters, or enrollments, you create a collection for exactly that, and it behaves like everything else: it can have stages, feed a report, be read by your site, and be acted on by an agent. Nothing is a second-class citizen for having been created by you rather than shipped by default.
What every entry carries
Beyond the fields you define, every entry has a few things by default — a name that identifies it, a URL-safe identifier, and a status that decides whether it is publicly visible. That status is worth knowing about early: entries begin as drafts, so nothing you create is public until you publish it. Your team sees drafts; visitors to a connected site do not.
How entries relate
Entries are not islands. An order points at the customer it belongs to; a booking points at the person who made it. Those links are references, and they are what turns a set of separate collections into a model of how your business actually works — covered in reference vs multi-reference. An entry can also move through stages, which is how a collection represents a process rather than a flat list.
Where this connects
The whole model these two words sit in is in understanding the Sonta data model. To shape one deliberately, read working with collections and fields; to build one hands-on, build your first collection; for the procedure itself, create a collection. Collections live inside one business and never span two.