Records

A record is one concrete business object in Moltaro. It might be a service request, asset, inspection, warranty case, customer resource, production item, approval, contact, entitlement grant, or another object your organization needs to manage over time.

The exact fields and screens depend on the record type. The purpose is the same: give the team one governed place for the facts, context, responsibility, and history of that object.

More than a form

A record is not just the form used to create it. The form is one way to enter or change information, but the record can also have:

• field values, such as names, dates, statuses, amounts, locations, and links;
• a readable number, display name, and other presentation values;
• related records or child information;
• object collaboration, tags, activity, and history when those features are enabled;
• assignments, permissions, and field-level visibility rules;
• links from boards, notifications, automation, reports, or module-specific workflows.

That is why two users may open the same record for different reasons. One person may update the operational facts, another may add evidence, another may review history, and another may only need the current status.

Where users see records

Users usually work with records through list pages, search results, detail pages, selectors, board items, notifications, related data sections, or reports. The same record can appear in several places, but it remains one business object.

For example, a warranty case could appear in a list of open cases, be linked from a customer record, be represented on a board, and show up in a report. Those surfaces are different views of the same underlying work.

What can change

Record changes are controlled by the record type and by access rules. Depending on configuration and permissions, a user may be able to:

• create a new record;
• edit some or all fields;
• send collaboration messages or files, or add tags;
• assign responsibility;
• archive or restore a record;
• run actions or move related process work forward.

If a field or action is missing, disabled, or read-only, it usually means the record type, current state, or the user’s access does not allow that change.

Editing values in a table

In record lists and in related tables on a record, you can change many values directly in the table cell, without opening the record form:

• Yes/No, choice lists and dates open with one click. For Yes/No, the second click on the checkbox saves the change; picking a single choice saves it too.
• A time zone opens the time zone picker with one click; picking a zone saves it.
• Text, numbers and money open with a double click, Enter, or by starting to type: the first character you type replaces the value. Enter or Save saves, Esc or Cancel discards.
• While the change is saved, the cell shows a small progress indicator. Each change is checked exactly like a change made in the form.
• If the change cannot be saved, the cell shows the stored value again and a dialog tells you which record (its number and ID) and which field, and what is wrong, for example that another required field is empty. From the dialog you can retry or open the record form; closing it drops the change.

Links to other records, users, files, addresses and Markdown text open the record form showing only that field. Saving it saves the record. Related records and nested rows are edited in their own related table, which supports the same cell editing.

Board and process columns offer their commands in the cell: click the board status to move the record on the board, and use the process column to start the process or respond to its current step.

An administrator can turn cell editing off for a table.

Access affects what users see

Moltaro treats access as part of the record experience. A user might be able to read one record type but not another. A user might see a record but have some fields hidden. A linked record might appear as restricted if the link exists but the user cannot read the target record.

This is deliberate. Moltaro should not make restricted data look like it does not exist, but it also should not expose details a user is not allowed to see.

Where to go next

• Read Record types to understand why different records have different fields and behavior.
• Read Fields and field types to understand the values shown on a record.
• Read Working with records for list, detail, create, edit, search, and import/export workflows.