Automation and business logic

Your workspace can enforce rules, fill in values, and run follow-up work automatically. You do not configure any of this — administrators do — but you will notice its effects while creating, editing, and browsing records. This page explains what you may see and why.

Fields that appear, lock, or become required

A form can change while you edit it. Depending on the record type, current values, and your access, a field may be shown or hidden, become required, or turn read-only. For example, a field may appear only for one customer type, or lock once a record leaves its draft state. The server enforces the same rules as the form, so a value that is required or read-only for you cannot be bypassed by another tool.

Saves that are rejected with a message

Validation rules check the whole record before it is saved. If a rule fails, the create, update, or import is blocked and you see the rule’s failure message — for example that a due date must not be before the start date, or that an amount exceeds a customer’s credit limit. The message tells you what to fix; correct the value and save again.

Values filled in for you

Some values are calculated instead of typed. A record can carry calculated fields derived from its other data, and before-save logic can set derived, normalized, or supporting values while the record is being saved. If a value changes on its own after you save, that is expected behavior, not an error.

Titles, subtitles, and highlighted facts

Record titles and subtitles compose themselves from record data, so lists and cards stay recognizable without decoding raw fields. Records can also carry named facts called statements — such as overdue, blocked, or needs review — that are calculated on the server. Screens use them for highlights and filters, and every screen sees the same fact with the same meaning.

Action buttons

Records and lists can offer action buttons for operations that go beyond editing a field: an action can check its context, update several values, create related work, or move a process forward. An action’s name describes its outcome; if it cannot run in the current situation, it tells you why.

An action may open a short input dialog before it runs. Boolean and choice fields can have defaults chosen by the action author; those values are part of the submitted action even when you do not change them. A field with no configured default stays unset until you edit it. Clearing a required field or a non-nullable defaulted field is deliberate input, so the dialog keeps the validation error next to that field instead of silently restoring the default. An untouched nullable Boolean without a default stays absent; after the operator changes its checkbox, the dialog sends the selected true or false value. Controls that expose a clear action send an explicit empty value.

Several records saved as one change

A command or an integration can save several related records as one change, for example an assistance record together with its legal detail. Either every record of such a change is saved or none is, so you never find only part of it. Each record is still checked against its own rules and the access of the person or service account making the change, and each gets its own history entry authored by that person or account. Retrying an interrupted change returns its earlier result instead of saving the records twice.

This applies only where a command or integration was built for it. Saving a form saves one record, and records saved one after another, by you, by an import or by other automation, are separate changes: when a later one fails, the earlier ones stay saved.

Automatic and scheduled work

Moltaro keeps recent submission results so retrying an interrupted save can return the previous result without applying it twice. These receipts expire after seven days and are cleaned up automatically. The number of saved receipts never limits new work. A conflicting reused request is reported as an error that your administrator can investigate.

Some work happens without anyone pressing a button. Triggers react after a relevant change — a new record, an update, a state change — and run the configured follow-up reliably. Schedules run recurring work at planned times, such as repeated checks, renewal windows, reminders, or cleanup. If a record changes shortly after you saved it, a trigger likely ran.

Scheduled runs do not overlap. If the target function still has work waiting in the queue or already running when the next planned time arrives, Moltaro records that occurrence as Skipped instead of starting a second copy. The administrator can see the skipped occurrence in run history; the active work continues normally.

Where to see what ran

Automated work leaves a run history: what ran, when, whether it succeeded, and what needs attention after a failure. This operational view lives in the Administration area, so if an automated result looks wrong or missing, ask your administrator to check the run history for the record and time in question.

For administrators and developers

How this automation is configured, authored, and monitored is documented in Business logic. The expression language behind validation rules, field conditions, statements, and calculated fields is documented in the expression language reference.

When trusted C# must authenticate to an external service, owners and administrators can provide a write-only credential through Managed secrets. The value cannot be revealed later; the page explains lifecycle, audit, and safe developer usage.