inmake DOCS
Docs / CRM & Studio / Content

Content

Collections and the localized document editor.

Data › Content is the project's free-form content: collections of localized documents shaped by a schema — pages, articles, recipes, anything the site renders.

Collections#

The Content page lists the registered collections (the project's setup/data registry). New collection names it, picks or creates its schema and, optionally, gives it a per-locale slug so the storefront can list it. Deleting a collection wipes its documents, its custom schemas and templates.

Groups organise a long list: Groups names, orders and removes them, and a collection's settings tick the groups it belongs to — any number, so one collection can appear under several. The page then shows one container per group, followed by Other collections for the ones no group claims; New collection in a group's header pre-ticks that group. Groups only organise this page — removing one never touches its collections, and nothing on the site reads them (setup/data groups[] + each row's groups).

Custom collections are saved views beside the real ones, much like a pinned menu group. Custom collection names one, then picks documents from any collections and/or adds whole collections. Opening it shows the picked documents together, in your order, then one block per added collection with its first rows (5 by default, Rows sets 1–30) and Show all to the full listing. A collection with Manual ordering is shown whole, in its manual order, and its rows can be dragged to reorder it right there (the same order its listing and the site use). Every block collapses from its header. New in a block's header creates a document in that collection without leaving the page — the same flow as the collection's own New (an optional id, then the editor; nothing is saved until you save it). A custom collection holds no documents of its own: deleting it changes nothing else, and the website and the API never see it. It sits in the Data page groups like any collection (setup/data custom[]).

A collection's settings also carry its query keys (Sortable filters) — the field combinations a listing may filter and sort by: equality on the leading fields, a range or sort on the last. Most listings need nothing declared: the platform derives Built-in keys from the collection's schema and shows them first, read-only, with their building / ready state and a Disable toggle. Declare your own key only for a shape beyond the built-ins (a number sort such as prep_time, a second enum); the platform indexes it for you (the key reads building until the existing documents are stamped, then ready), and a listing that needs a key it does not have says so with the fields to add (query_key_required). The shape and limits are in Listing and pagination › Query keys.

Built-in keys#

Derived from the schema template (schema order decides "first"; up to five, on their own budget beside the eight keys you may declare):

Built-in key Fields Serves
status_timestamp status, timestamp "published, newest first" — every collection
status_{date} status, the first two datetime fields "published articles by publish_date", date ranges
{enum}_{date} the first enum field, then the first datetime field (else timestamp) "category X, newest first"
status_{enum}_{date} status, the first enum field, that date the same, published only

Recipes with an enum category and no date field get status_timestamp, category_timestamp and status_category_timestamp; articles with a publish_date get status_timestamp and status_publish_date. Number, boolean and array fields derive nothing.

Products (the storefront's products mirror) have a fixed set — status_price, status_name, status_timestamp — and their category and tag pages (an array filter with a sort by price, name or newest, plain or published-only) run on platform indexes every project shares; one array filter per listing ("category X and tag Y" filters the second in memory, or adds a scalar field with a key).

Disable removes a built-in from the collection (keys: {"<name>": null} on the row); declaring a key under the same name overrides it. Built-ins build lazily — the first listing after they appear starts the backfill; until ready the listing runs unkeyed.

→ the full list, generated from the index file: Indexes

Documents#

A collection lists its documents from the primary locale; every document exists once per project locale, so the editor shows one tab per locale plus a shared General tab for fields the schema marks locale-independent. Fields render from the schema: text, rich text (a toolbar editor with the design system's colours), numbers, dates, images and files, references to other documents (with a query builder), element placements, enums.

Create asks for an ID and a template and opens the empty editor — the record exists only once you save it, so backing out leaves nothing behind, and required fields must be filled before the first save. The editor's side trees carry the document's SEO and structured data; the Reorder tab changes the schema's field order across tabs; the assistant column edits the document in conversation and can create sections and place elements.

A document's status (draft / published) decides whether the site renders it. Changes are saved per locale; the platform pushes them to the project's render servers through the data hooks within a second.

Save, Save and close#

Save at the bottom of the editor has a small arrow: pick Save (stay in the document) or Save and close (save and go back to where you opened it — the listing, a custom collection, the dashboard). What you pick is remembered for your account and becomes what the button does next time. The save icon at the top and Ctrl+S (⌘S on a Mac) always just save and keep the document open.

Saving safely#

Every save replaces the stored document, so the editor checks first whether the document changed in the database after you opened it — in another tab, by a colleague, by the assistant or through Live Edit. If it did, a dialog offers Reload (drop your edits and load what is stored), Overwrite (save anyway; the activity log records it as Overwritten) or Show changes (field by field, with the ones you edited too marked). Housekeeping the platform does on its own — query keys, product mirrors, ledger totals — never counts as a change.

While you type, the editor keeps a draft in your browser; a "Draft saved" chip sits next to Save. Nothing is written to the project until you save. If the tab was closed or the browser crashed, the next time you open the document a banner offers to restore the draft or discard it.

History#

The document menu (⋮) → History lists the last 20 saves of the open locale (kept for 90 days) — whoever made them: the console, the assistant, an integration. Select one to see what differs from the current form, and Restore to load it into the form; Save then writes it (and records a new revision).

Cross-environment sync#

Sync copies a document between Demo and Production (or back) — a managers' shortcut over secure/syncStore.

Access#

The content capability; write to edit, create or delete.