Skip to content
Moltaro 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.

Common field families include:

  • text values for names, descriptions, notes, and identifiers;
  • numbers and decimal values for counts, quantities, amounts, and measurements;
  • dates and times for due dates, effective dates, appointment times, and schedules;
  • yes/no values for simple flags;
  • selectable values for controlled lists such as priority, category, or state;
  • user and role fields for people or access-related references;
  • file fields for selected files;
  • address fields for location information;
  • reference fields that point to another record;
  • table fields 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.

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.

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”