Fields & objects

The app comes with its own records: clients, products, the CRM's businesses, projects, vendors and the rest. What your business knows that the app has no column for goes into fields of your own, kept on those records; and what the app has no record for at all (a property, a batch, a certificate, a piece of equipment) becomes a kind of record of your own, with its own fields and its own list. Both live in one registry, under Settings, Records, Fields & objects, and every change to it is drafted, reviewed and published as a numbered version, so what a record means never changes under anyone's feet.

Adding a field

1. Open Settings, Records and Open Fields & objects. A product's More about it card says the same.
2. Pick the kind of record along the top: Products, your clients, the CRM's businesses, Opportunities, Projects, Vendors, or a kind of your own.
3. Add a field: its name, what it holds, what it means in a sentence, and its meaning as a tag (such as contact.birthday or money.cost), so the assistant and your team read it the same way. Mark it Needed when a record must have it, give it a default, and on a product choose Show it on the website.
4. Add to the draft. The field is on no record yet: it is in the draft at the top of the screen.
5. Publish the draft (or Send for review first). From then on the field is on every record of that kind: on a product under More about it, on a kind of your own on each of its records.

What a field holds: a line of text, a paragraph, a number, money, a date, a time of day, yes or no, one or several of a list you set, a link, a link to another record (the relationship between two kinds), someone on the team, or a file by its name and link.

A field's key (shelf_life_months) is what formulas and the API call it; it is set once. Its name on screen can change any time, through the draft.

Changing and archiving a field

A field is changed through the draft too: tap its pencil, change its name, meaning, choices, default or whether it is needed, and Keep in the draft. A field that already holds values keeps its type: to hold something else, archive it and add a new one. Archive takes a field off the screens and the API while keeping every value it held; Bring it back returns it. Nothing is ever deleted.

Formulas

A field can be worked out rather than typed: switch on Worked out by a formula and write it from the record's other fields by key.

• Arithmetic: price - cost, round((price - cost) / price * 100, 1), price * qty * (1 + rate)
• Words joined with &: brand & " " & name, name & " (" & size_ml & " ml)"
• Choices: if(price > 20, "Premium", "Everyday"), coalesce(discount, 0), is_blank(notes)
• Comparison and logic: price > cost and vegan, not vacant, =, <>, <, <=, >, >=
• Dates: days_between(bought_on, today()), add_days(due, 30), year(since), weekday(today()); today is the business's own day, so the same formula gives the same answer wherever it is read
• Over the records that belong under one, or link to it: sum(units.rent), count(units), max(units.rent) - min(units.rent), avg(units.rent)

The functions are if, and, or, not, abs, round, floor, ceil, min, max, sum, avg, count, len, upper, lower, trim, concat, contains, starts_with, replace, left, right, text, number, coalesce, is_blank, today, date, days_between, add_days, year, month, day and weekday. There are no loops and nothing reaches outside the record, so a formula always gives the same answer for the same values. A formula is checked as you type it, against the fields and lists it may read; one that cannot be worked out on a record (dividing by an empty field, say) says why on that record in a sentence, and the rest of the record is fine. A formula field is worked out each time the record is read and is never typed.

Kinds of record of your own

Add a kind of record: what one is called, what several are, an icon from the app's set, what it is for, whether each belongs under another of your kinds (a unit under a property), and who sees it: everyone at the business, or the logins with one switch (Pipeline, Stock, Projects…). To belong to a product or a client, give it a field that links to one; a formula on the product can then add up the records that link to it.

Once the draft is published, the kind's records are under Memory, Objects: a grid of them, searched by name and sorted by any column, fifty to a page; Add a record with its name and fields; each record opened with its fields, the records under it, and what was done to it. A record is archived rather than deleted, and comes back when it is restored.

The draft, review and publishing

Every change goes into one open draft, shown at the top of Fields & objects with each change in a sentence and its risk, set by rule: a new field or kind is low; a changed name, meaning, default or choice is medium; a changed type, link or formula, a field made needed, or an archive is high. The set's risk is its highest. Give the set a name and a note for whoever reviews it.

• Send for review moves the draft to review: nothing more goes into it until it is published or moved Back to a draft.
• Publish applies every change at once and gives the registry its next version number, which only goes up. A high-risk set is published only from review.
• A published set is never edited; the next one supersedes it. What was published lists every version with its changes.

Drafting takes the Fields and objects switch (on for admins and managers); publishing takes Business settings as well. A field the app adds on your behalf (a sheet brought into products with a column of its own) is published at once as a one-change set, so the history says where it came from.

Through the API and the assistant

The Fields and objects part of the API reads the registry (/fields, /objects), lists and changes the records of your own kinds (/objects/{key}/records), sets a product's or a client's registry fields (/records/{object}/{id}/fields), drafts changes and publishes them (/change-sets), and lists your apps (/apps). A program with the part changes records at once; an AI asks a person first, as your rules for programs and AI say under Settings, Approvals. Webhooks and workflows hear field.published, record.created and record.updated. The assistant in the app, and an assistant connected through MCP with the Fields and your own records permission, read what each field means with fields_describe and your own kinds' records with records_search and record_read; a kind a switch opens is kept from them.

Apps

Under Admin, Modules, Apps, a program of your own, or one a developer built for you, is declared: its name, the parts it may read and change, and the events it hears and where. Installing it makes an API key with exactly those permissions, shown once, and a webhook for exactly those events, so it works under the same rules as any program and everything it does is in the activity log. Pause turns its key off; New key replaces a lost one; Remove takes its key and webhook away.

Best practices

• Say what a field means in a sentence, and tag it. "Birthday" with contact.birthday lets the assistant answer "who has a birthday this month" without guessing.
• Keep a field's key stable: formulas, the API and your apps call it by the key.
• Make a field needed only when every record truly has it; otherwise an old record cannot be saved until someone fills it in.
• Name each change set for what it does, so the history reads well a year on.