Custom Fields

Custom fields put structured data on your documents — a status, an owner, a version. A project with fields reads like a catalog instead of a pile of pages.

You define fields once per project, and every document in it shares that schema. Dundler Paper’s DundlerOS API project defines Status, Owner, and Reviewed. Every API page now carries those three, and the Tree Filters & Sorting by any of them.

Define fields

Prerequisites: You need write access to the project.

1. Open your project’s Overview → Custom fields.
2. Select Add field.
3. In Label, enter the name people see on documents. The Key — the identifier used in Configuration and the API — is derived from it.
4. From Type, select one of the types below.
5. Optionally set a Default (see Default values).
6. Select Save.

Field types:

• String (text) — free text.
• Number — numeric values; sortable in tree filters.
• Boolean (yes / no) — a toggle.
• List (tags) — multiple free-form values.
• Select (one of…) — one value from a fixed list of options.

Drag fields by the handle to reorder them — the order you set here is the order they appear on every document.

A field’s type and key are fixed once it exists. The label can be renamed freely, but changing what a field is would leave every value already stored under it meaning something else, so it is refused. If you picked the wrong type, add the field you meant and delete the other one.

Select options — rename without breaking documents

You edit a select field’s options in the same dialog. Rename one, and Meldoc migrates every document holding the old value across to the new one. Nothing is left pointing at an option that no longer exists. Renaming two options to the same name merges them.

Deleting an option that is the field’s current default is rejected — set a different default first.

Default values

A default fills the field on every document that doesn’t set its own value. Change the default, and every document that inherits it updates instantly — nothing is rewritten document by document.

On a document, an inherited value is marked Inherited from the project default. The moment someone sets a value explicitly, that document stops following the default — even if the value they typed happens to match it.

Keep in mind: Inherited values live on the project schema, so a document’s Version History won’t show the moment a default changed. That change is recorded once, in the project’s Audit Log.

Fill fields on a document

Fields sit at the top of every document, above the content. Anyone with write access can type or pick a value there.

Clearing a value is not the same as leaving it alone. A cleared field stays empty even when the project default changes. That’s how you say “this one genuinely has no owner.” To hand the field back to the default, select Reset to default.

Field values ride along in a document’s version history, so a value someone cleared can be brought back.

Document layout

The Document layout setting sits above the field table. It controls how fields render on documents in this project: as a table, an inline row, or a stacked list. Layout changes presentation only, never values.

Fields everywhere else

Tree filters — filter and sort the document tree by any field, straight from the sidebar.

CLI — field values sync through the fields: block in frontmatter. Inherited values are deliberately not written into pulled files, so a pull-then-push never pins a default as an explicit value.

MCP — AI assistants can read and manage fields with the fields_list, fields_define, fields_update, fields_delete, and doc_fields_set tools: see MCP Tools Reference.

What’s next?

Tree Filters & Sorting — Filter and sort the document tree by field values.

Project Settings — The rest of your project’s configuration.