Skip to main content
This is the complete surface a field rule can call. Everything listed here is in scope inside a rule body — no imports, no setup.
New to rules? Read Field rules first. It covers events, function naming, and how to build a field key — the parts you need before any of this is useful.

The field object

Every field on the form is reachable as field.<fieldKey>. Inside an OnChange, OnBlur, OnFocus, or OnClick handler, the argument you receive is that same object, so value.getValue and field.<its own key>.getValue are equivalent.

Reading and writing the value

setValue takes an object, not a bare value: setValue({ value: 'abc', onchange: false }). Passing a bare value does nothing.On foreign and selector fields, pass only the id — not a hand-built object.
getValue on a table or detail field does not return the data painted into it. If you need that data at submit time, rebuild it in the submit handler rather than reading it back.

Validation state

Visibility and interaction

setVisible and setRender are no-ops in table render context. For behavior that must work in a table, change values, errors, or enabled state instead.

Identity

Events

Call the on* members to re-trigger a field’s own event. Call the setOn* members to replace a handler at runtime — rules normally attach through the Page Designer instead, so these are rare in a rule body.
Never re-trigger a field’s own event from the rules that write into it. If several source fields call field.<target>.onChange(), the target’s OnChange becomes the composition handler — and typing directly into the target then overwrites the user’s input. Write with setValue({ onchange: false }) instead.
OnChange handlers are debounced by 500 ms. Set _delay on the handler function to change it — for example myHandler._delay = 0 for no debounce.

Extra properties

setProperties(props) sets field-type-specific options. On a date field, for example, it constrains which dates can be picked:

Form helpers

failfast.myFormHelpers controls the form as a whole. These are what OnLoad, OnSubmit, and OnDelete rules work through.
handleSubmit() can fail. Always check the result before continuing — especially on an embedded form, where a failed save would otherwise be followed by steps that assume it succeeded:
Use throw result instead of return when the surrounding rule must also stop.

Note helpers

failfast.myNoteHelpers reads and writes the form’s note. All three are asynchronous — if the editor hasn’t mounted yet, the call waits and applies once it does.
Writing to the note counts as a user edit and is saved the same way. An OnLoad rule that writes to the note will overwrite what is already saved unless you stop in edit mode first:

Workspace context

failfast carries information about who is working and in what context. field and failfast are the same object, so either name works.
Guard behavior that only makes sense on a full form with if (failfast.typeRender === 'table') return. The same rule runs in both contexts.

Context actions

Services and processes

Registries

Four names give a rule access to fields — the difference is which form’s fields they hold. These are live objects, so anything you assign to one is visible to every rule that runs afterwards. That is how you share a helper between rules — see sharing logic.
page keys share a namespace with form identifiers, so put your helpers under one container such as page.__helpers rather than at the top level.page is never cleared, so a helper defined by one form is still there after you navigate to another. Always reassign it (page.__helpers.x = …) instead of only defining it when missing, or a stale version from a previous form will be used.

Built-in objects

These are in scope in every rule body.
await works anywhere in a rule body — asynchronous handling is applied for you.Load related data in one request using the fields parameter rather than one request per relation. fields=customer__name,customer__document_number walks forward through relations; a reverse relation comes back as an array. The request and response formats are documented in the API reference.

Shared helpers

These functions come from your workspace’s rule catalog and are callable by name from any rule.
The fields array you pass to validateOnSubmit must include every field the record requires — not only the ones a condition touches. Anything you leave out is not validated, reaches the save, and fails there without a message the user can act on.
Your workspace may define additional catalog helpers beyond these four. Open the Code menu in the Page Designer to see what is available.

Selector configuration

An OnClick rule on a selector field returns a configuration object. Every key is optional — return only what you need.

Return values by event

Field rules

Events, naming, field keys, and the patterns these methods are used in.

Page Designer

Where rules are attached, under the Code menu.