Beyond its fields, every xMatix entity carries six declarative behavior surfaces: saved list views, save-blocking validations, action buttons, create-time field mappings, picker-restricting lookup filters and dependent-picklist field dependencies. All six are configured on the entity itself in Setup → Design Studio → Entities — no code — and all six can be scoped to a record type. This page is the reference for what each one does, where it lives, and the sharp edges each carries.
| Surface | What it does | Where it lives |
|---|---|---|
| Views | Saved list definitions: columns, filter, sort, grouping, default | Entity → Experience → Views |
| Validations | Declarative save checks with a message | Entity → Logic → Validations |
| Actions | Buttons on the record page or list that run platform or custom behavior | Entity → Logic → Actions |
| Field mappings | Auto-fill fields from a looked-up record at creation | Entity → Schema → Field Mappings |
| Lookup filters | Restrict which records a lookup's picker offers | Entity → Schema → Lookup Filters |
| Field dependencies | Narrow a picklist's options based on another field or a condition | Entity → Schema → Field Dependencies |
Views
A view is a saved list: the columns (picked and ordered explicitly), a filter condition baked into the definition, a sort order, and optionally grouped or tree presentation. Views can be scoped to a record type, and one view per entity (and per record type, when scoped) is the default that list pages open with. The filter and sort use the query-filter expression language; user-applied filters at run time are combined with the view's own.
Two behaviors to know. A view with no columns still renders — with generic fallback columns, which users read as breakage — so always define columns. And a filter that names a nonexistent field fails when the view runs, not when it is saved; open the view once after authoring it.
Validations
A validation is a declarative save check: a condition that, when true, marks the record as violating, plus a message and a severity. Only Error severity blocks the save — Warning and Info display without blocking, so "prevent saving" always means Error. The message can be placed at the top or bottom of the form or attached to a specific field, and the whole validation can be scoped to a record type. Validations run inside the save pipeline for every write path — forms, API, imports — not just the form that displays them; see what runs when you save a record.
Validation conditions are formula expressions over the record being saved, with a deliberate limit: no aggregates over child records. A condition that needs "sum of the lines" or must compare old and new values belongs in a business rule instead. The classic silent failure is comparing a picklist field against a value that is not in its domain — usually the display label instead of the stored value — which produces a validation that can never fire; check stored values before writing the condition, and re-check them when auditing validations someone else wrote.
Actions
An action puts a button on one of three surfaces — the record page, the list header, or each list row — and gives it a type: the built-in behaviors (new, edit, view, delete, preview, print), a UI action, or a server action that runs logic on the server. Actions can show a confirmation dialog first, be scoped to a record type, be ordered among their peers, and run asynchronously as a background job when the work is slow.
Server actions are the extensibility point: the button dispatches a named action to the server, where either a built-in handler or a bound automation script (or both — the script runs in addition to the handler) does the work. The trap is that a server action with no handler and no script binding is not an error: the call succeeds and nothing happens. "The button does nothing" almost always means the script binding is missing or points at a different action name — and because the binding matches on the action's name, renaming an action re-keys its trigger.
Field mappings
A field mapping copies a value from a looked-up record into the new record at creation: pick an item on an order line and the price fills in, pick an account and its region lands on the claim. Each mapping names the lookup that triggers it, the source field on the looked-up entity, and the destination field; the editor offers only type-compatible source fields.
The semantics are exactly create-time and best-effort. Mappings run only when the record is created with the lookup set — changing the lookup on an existing record does not re-copy, and a mapping that cannot apply (source missing, types diverged) skips silently rather than failing the save. The mapped value also overwrites whatever the creator typed into the destination, so never map onto a field users are expected to fill themselves. For copy-on-change behavior, use a business rule that copies from the related record when the lookup changes.
Lookup filters
A lookup filter restricts what a lookup field's picker offers: only active accounts, only items of the record's own category, only warehouses in the user's region. The condition is a query-filter expression over the target entity's fields, and it can reference the host record's current in-form values, the current user, and environment values — so "accounts in the same region as this claim" is one condition, evaluated live as the user fills the form. Filters support record-type scoping on both sides: which host record type the filter applies to, and which target record type the picker is limited to. Only the first matching filter applies per lookup and host record type, so do not stack active filters on one lookup.
Two limits matter. A lookup filter constrains the picker only — a direct API write can still set any id, so a hard constraint needs a validation or business rule behind it. And an over-tight or misspelled condition does not error; it silently yields an empty picker. Always test with a record that should match.
Field dependencies
A field dependency narrows a picklist's options while the user edits: choose "Hardware" in the category field and the subcategory field offers only hardware subcategories. Dependencies come in two shapes — on a picklist field, where each value of a controlling picklist maps to the allowed dependent values, and on a condition, where rules with conditions (over the record's fields, related records or the current user) decide the allowed set, with configurable behavior when no rule matches (all values, no values, or a default set). Enforcement is also configurable: warn on an out-of-set value, block it, or auto-clear the dependent field when the controlling value changes. Dependencies are authored from the entity's Schema → Field Dependencies tab or directly from the field list.
Like lookup filters, dependencies shape the editing experience; data already stored, and writes that bypass the form, are not retroactively policed — pair a dependency with a validation when the combination must hold absolutely.
Common questions
When do I use a validation and when a business rule?
Use a validation for a self-contained check on the record being saved — a format, a range, a required combination — where a condition plus a message is the whole requirement. Use a business rule when you need anything more: triggers (only on create, only when a field changes, only on a status transition), aggregates over child records, conditionally required or read-only fields, derived values, or post-save follow-ups. Both block server-side across every write path; the rule simply has more machinery.
Can I rely on a lookup filter or field dependency for data integrity?
No — both shape what the form offers, not what the database accepts. API writes, imports and integrations can set values the picker would never have shown. When the constraint is a business requirement rather than a convenience, express it twice: the filter or dependency for a good editing experience, and a validation or business rule for enforcement.
Why did my field mapping not update the record when I changed the lookup?
Because mappings run only at record creation — that is their contract, not a malfunction. Re-copying on change is deliberately left to business rules, where you control the trigger (when the lookup field changes) and whether existing values may be overwritten. Keep the mapping for the create path and add a rule for the change path when both matter.