Skip to content
MoltaroMoltaroMoltaro Docs

Fields and field types

A field is one named piece of information on a record. Fields hold the values people enter, review, filter, search, report on, and use in rules.

Examples include a title, requested date, due date, status, amount, contact, location, owner, attachment, related asset, or long description. The exact fields depend on the record type.

Field types

Section titled “Field types”

The field type controls what kind of value a field can hold and how Moltaro can display or validate it. The names below are the same names configurators see in the Constructor field editor:

  • String and Text for short single-line values and long multi-line descriptions or notes;
  • Whole number and Decimal for counts, quantities, and measurements;
  • Money for an amount together with its currency;
  • Date for a calendar date, Time for a time of day, and Date and time for one exact moment such as a scheduled start, handoff, or deadline;
  • Yes/No for simple flags;
  • Select for controlled choices such as priority, category, or state — a Select field can allow one choice or several;
  • Classifier for one category from a shared hierarchical Classifier Catalog used by several record types;
  • User and Role for people and role values;
  • File for governed file attachments stored on the record;
  • Address for structured location information, optionally with map coordinates;
  • Reference for a link that points to another record;
  • Inverse reference for the reverse view: the records whose reference points at this record;
  • Table for repeatable child rows inside the record.

Users usually do not need to think about the storage details. The field type matters because it shapes the input, validation, search behavior, and display.

Date and time values

Section titled “Date and time values”

A Date and time field is one field, not a separate date plus time-zone setting. Moltaro displays it in the workspace time zone. The editor accepts date and time to the minute and never asks the user to choose or edit an offset.

The stored value is still an exact moment. Values supplied by an integration may include seconds and microseconds; opening or viewing the field does not erase that precision. If a user changes the value in the minute-precision editor, the newly selected value starts at zero seconds. Local times that do not exist or occur twice during a daylight-saving transition are rejected instead of being guessed.

Filters use the same minute precision. Equals matches the complete selected minute, including values supplied by integrations with seconds or microseconds. Not equals excludes that complete minute. Greater than starts after the selected minute, less than or equal includes the complete selected minute, and Between includes both selected endpoint minutes. The offset remains hidden and Moltaro applies the workspace time zone before comparing the exact stored moments.

Markdown text

Section titled “Markdown text”

A configurator can label a String or Text field as Markdown. Record details then show safe formatted headings, lists, task lists, tables, links, quotes, and code, while lists and history use a compact plain-text excerpt. Create and edit forms provide Source, Preview, and desktop Split modes without changing the outer form’s Save and Cancel behavior.

On record, Association-create, Board-target, and Board Data forms, Markdown images can be added by upload, clipboard paste, drag and drop, or File System selection. Moltaro accepts inspected PNG, JPEG, and WebP content only. Remote images, SVG, raw file URLs, and embedded data are never fetched. An image remains part of its exact destination draft until the outer form saves successfully; cancelling the form does not create a durable attachment. Composite Board create keeps target Entity and Board Data drafts separate, and Board access never grants access to an otherwise unreadable target Entity image.

Required, read-only, and editable fields

Section titled “Required, read-only, and editable fields”

Some fields are required before a record can be saved. Some fields are read-only because they are calculated, controlled by a process, protected by permissions, or set by the system. Some fields may be editable in one state but not another.

A configurator can also give supported fields a default value for new records. Fixed defaults appear in the create form; Date and Date and time fields can instead use the current date or current moment when the record is saved. For a multi-select, choose one or more distinct configured options. For a Reference, use the record picker: Moltaro stores only the selected record ID and resolves its Number and Display Name according to current access. Defaults never overwrite an explicit value and are not reapplied during edits. See Fields and schema for the supported field types and exact behavior.

Required, visible, and editable are configured as rules, not fixed flags. A field can be required only under a condition, and a rule can apply when a record is created, when it is updated, or both. This is why the same field can behave differently on a create form and an edit form.

When a field cannot be changed, the reason is usually one of these:

  • the record type does not allow manual edits for that field;
  • the field is controlled by a rule, action, import, or integration;
  • the record is in a state where that value should not change;
  • the current user can read the field but cannot edit it;
  • the current user cannot read the field at all.

Display values

Section titled “Display values”

Records often show a display name, subtitle, or other display-only values so lists and links are readable. These values help users recognize records without opening every detail page.

A display value may be derived from one or more fields. It should be treated as presentation, not as a separate field users edit directly unless the screen shows an editable source field.

Field access

Section titled “Field access”

Field access can be more specific than record access. A user may be allowed to open a record but not read every field on it. Another user may be able to read a field but not edit it.

This is common for sensitive values, internal notes, financial information, or fields that only a responsible team should manage. If a field appears restricted or is absent from a screen, the record type and access rules determine that behavior.

Where to go next

Section titled “Where to go next”