Working with collections and fields

Most CRMs come with their objects already decided: here are your contacts, here are your deals, work within them. Sonta starts from the opposite place. It gives you collections and fields as raw material, and you shape them into the model your work actually has. This guide is about that shaping — what a collection is, how you make one, how fields carry and connect your data, and when to let a blueprint do the setup for you.

Why you shape your own model

The practical difference is this: there is no fixed, hardcoded set of objects you have to bend your work into. If your business runs on work orders, or properties, or matters, or shipments, you make a collection for exactly that — not a repurposed deals table with a note field standing in for what you really track. A new collection or field takes minutes, with no code and no schema migration, so the model keeps pace with how you actually work instead of waiting on a release. That is the part worth internalizing: the model is yours to change, continuously.

The cost of that freedom is judgment. When anything can be a collection or a field, you have to decide which it should be — and a model built without that discipline turns into a drawer of half-used collections. Two habits keep it clean, and each has its own page: deciding how records should link, and knowing when a new field is enough versus when something deserves its own collection. The freedom to shape the model earns its keep only when you spend it deliberately.

Beyond the spreadsheet

If you have read the data model guide, you already have the picture: a collection is like a table, an entry is a row, a field is a column. Hold that as the starting point — then notice where a spreadsheet stops and a collection keeps going. A spreadsheet column holds whatever you type; a Sonta field has a type, so an amount stays a number and a date stays a date. A spreadsheet cannot say that a row here is the same customer as a row on another tab; a collection can, through a reference. And a spreadsheet has no idea whether a row is in progress or done; a collection moves an entry through stages. The same familiar grid to start from, with the parts that make it a system rather than a sheet.

Creating a collection

There are two ways to get a collection, and the right one depends on how standard your need is. If it is a common setup — a sales pipeline, a set of contacts and companies — a blueprint installs it ready-made, with its fields and stages already in place; you adapt rather than assemble. If what you track is particular to your business, you create the collection yourself and shape it from there. Either way the first decision is the same, and worth pausing on: what does one entry represent? One work order, one property, one enrollment — naming that precisely is what makes every later field obvious. The housekeeping fields every collection needs — its name, a URL-safe identifier, its publication state — are added for you; you never set those up by hand.

Adding fields

A field is a column, and the choice that matters when you add one is its type. The type is what turns raw text into data the system can work with: a number you can total, a date you can put on a calendar, a fixed set of options you can filter by. Pick the type that matches what the field really holds, because a field's type is set when you create it and does not change afterward — switching later means adding a new field and moving the data across, not changing a setting. That one constraint is the reason to choose deliberately rather than reach for a plain text box for everything. Alongside the type, a field can be marked required, unique, or searchable, depending on the role it plays.

Fields that connect and compute

Two kinds of field do more than store a value. A reference links an entry to an entry in another collection — a work order to its customer — so the two stay connected without copying anything. Whether one link or several is right is its own decision, covered in reference vs multi-reference. The other kind is derived: a rollup or a lookup pulls a value across a reference — the total of a customer's orders, or the customer's city shown on the order — and Sonta keeps it current for you. Because these are computed, you do not write to them; they update themselves as the underlying records change.

Shape it yourself, or install a blueprint

It is worth being deliberate about which route you take. Hand-building is right when the shape of your work is specific and you want it modeled exactly — no leftover fields you do not use, none missing that you do. A blueprint is right when your need is well-trodden and you would rather start from a working setup than an empty collection; you install it and adjust. The rule of thumb: build what is yours, install what is standard. You do not hand-assemble what a blueprint already ships — that only recreates work already done well.

A worked example

Take a repair shop that wants to track jobs. It creates a Work Orders collection — one entry per job — and adds a handful of fields: a status, an amount as a number, a scheduled date as a date. It adds one reference, from each work order to the customer it belongs to, so a customer's history is one link away rather than retyped on every job. The shop's jobs then move through stages — booked, in progress, done — and the same records show up as a board the front desk watches and as figures the owner reads at the end of the week. Swap the repair shop for a clinic tracking visits or an agency tracking projects and nothing about the method changes; only the collection and its fields do.

Where to go deeper

For the model these pieces belong to, read understanding the Sonta data model; for the linking decision, reference vs multi-reference; and if you have not set up a business yet, create your first business first. The step-by-step tasks — creating a collection, adding and changing a field, configuring a rollup — each have their own how-to in this section.