Building
Data structures
Types, records, links between them, and the moment a type earns a table of its own.
CogniWork has no built-in domain. There is no Contact object waiting for you, no Project, no Task. You describe what you keep track of and the types appear.
Find them under Data structures in the sidebar.
Three kinds of type
Plain — a standalone type with whatever fields you name. Lead, Invoice,
Inspection, Recipe. Most of what you create is plain.
Composite — a type that extends a parent and adds its own fields. If every Asset has
a serial number and a location, and a Vehicle is an asset that also has a VIN and a
mileage, then Vehicle is composite on Asset. Records show up in both places, and a
query over assets includes the vehicles.
Association — a link between two types, many-to-many. A Lead can have several
Campaigns and a Campaign has many Leads; the association holds that relationship and
can carry fields of its own, like the date the link was made.
Ask for what you mean and the right kind gets chosen: “every vehicle is also an asset” or “leads and campaigns are many-to-many” is enough.
Fields
Field types are deliberately few:
| Type | Use for |
|---|---|
string | Short text — names, codes, single-line values |
text | Long-form text — notes, descriptions |
integer | Whole numbers — counts, quantities |
float | Decimals — amounts, rates, measurements |
boolean | Yes/no flags |
datetime | Dates and timestamps |
uuid | Identifiers, including references to other records |
Fields can be required or optional. Add, rename and remove fields whenever you like — existing records adapt rather than break.
Records
A record is one instance of a type. Create them by asking, by importing a file, or by hand from the type’s page.
Deletion is soft by default. A deleted record leaves your views and queries but is not shredded, so an accidental delete is recoverable — ask the assistant to bring it back.
Calculated values
You can define fields whose value is derived rather than stored — a total, a days-since, a status computed from other fields — and aggregates across a whole type, like a sum or a count by group. Ask for the number you want (“total invoiced per client this quarter”) and it gets defined once and reused everywhere.
Graduating a type
New types start flexible: their records live in a shared, schema-less store so you can change your mind cheaply. That’s the right trade-off while a type is still moving.
Once a type has settled and holds real volume, graduate it. Graduation gives the type its own proper table with real columns and real indexes. Queries get faster, and the shape stops being negotiable — which by then is what you want.
- Graduate from the type’s page, or ask the assistant to do it.
- Your records come with it; nothing is lost.
- You can keep evolving the type afterwards; it just becomes a more deliberate act.
Rule of thumb: graduate when you’ve stopped renaming fields and started caring about speed.
Importing
Drop a file in your drive and ask the assistant to import it. It reads the file, proposes a mapping from columns to fields, tells you which rows it can’t parse, and waits for your go-ahead before writing. If the type doesn’t exist yet, it will offer to create one from the file’s shape.
Locking a record
A record can be locked while something else is working on it, so two workers don’t write over each other on the same row. You’ll rarely set this yourself — it matters when several automations touch the same data — but it’s why a long-running import doesn’t corrupt what you edit at the same time.
Next
- Saved views — turning types into pages you actually look at.
- Workflows & triggers — reacting when a record changes.