Custom objectsAuthoring
Model what has no template. Name it, give it fields, relate it to real people, and it exists, with the same views and machinery as everything we built ourselves.
Define it the way you say it. Because the words are the model.
An equipment loan is an item, a borrower, two dates and a deposit. Say that in the authoring form and you have said everything: the views, the import and the API arrive with it.
- Name it in the singular and the plural: the UI uses both
- Pick the view it opens on: table, board, calendar, list
- Relate it to a contact, organization or household
- Fields from sixteen types, required where you say
- Stages only if the work moves; many don’t, and that’s fine
The sixteen field types. Twelve values, four relations: the relations are the point.
- Field types
- Text
- Long text
- Number
- Currency
- Date
- Date and time
- Checkbox
- Select
- Multi-select
- URL
- Phone
- Link to a contact
- Link to an organization
- Link to a household
- Link to another record
Let each team read it their way. One set of records, many views.
The coordinator’s board and the bookkeeper’s table never fight, because a view is just a filter, a sort and a layout on top of the same records.
- A view is a filter, a sort and a layout, saved with a name
- Board for the coordinator, table for the bookkeeper
- Shared with the account, or personal to its creator
- Group by stage, by month, by whatever the field allows
- The records are one set: the views are how each team reads it
Why it holds up. Three properties worth naming.
Validation you author
Set length limits and a pattern on text, ranges and integer-only on numbers and money, and it holds at save time in the app, not just as a hint in the form.
Sixteen types is a vocabulary
Most record types are ten fields of text, dates, money and a relation. The four relation types are the ones that matter: they tie your model to real people rather than to strings.
Nothing is trapped
Mapped CSV in, CSV out, and every type readable over the API with scoped tokens. The model is yours to leave with, which is exactly why you can commit to it.
Nine types already exist. Check the templates before you author.
No. Authoring is the app: name, fields, relations, stages, views. Sixteen server actions behind buttons, not a schema migration.
No. There are no formula fields and no cross-object rollups today. If a number needs computing, it is computed by a person or a workflow, and we would rather tell you that than have a spreadsheet column quietly not add up.
Neither yet. Validation today is lengths, patterns and ranges: real, enforced, and deliberately narrow while the framework hardens.
Yes: add fields, reorder them, adjust stages and views. Display names can change any time; the underlying field keys stay stable, which is what keeps your imports and API reads working.
Read-only today, with scoped tokens. Records go in through the app and the CSV import; they come out through export and the API.