Business rules · Documentação

A business rule reacts when a record in a table is created, updated, deleted, or restored. Rules keep your data correct on every save, no matter where the save comes from: a form, a kanban drag, the API, or a workflow step.

Rules run inside the save itself, as part of the same database transaction. If a rule refuses the save, nothing is stored. If a rule writes to another table and that write fails, the original save can be undone too.

The four rule types#

Type	What it does	When it runs
Computation	Fills a field automatically	Before the record is stored, first
Validation	Checks the data and reports what is wrong	Before the record is stored, second
Guard	Blocks a change outright	Before the record is stored, third
Side effect	Writes to other tables, or starts a workflow	After the record is stored, in the same transaction

Every computation finishes before any validation starts, and every validation finishes before any guard starts. So validations and guards always see the values computations filled in. Within one type, rules run by their Order: lower runs first.

Create a rule#

Open any view on the table, click Settings, and choose Business Rules.
Click New rule.
Enter a Name, such as "Approved orders cannot be edited", and optionally a Description.
Pick a Rule type.
Under Runs on, choose the operations: Create, Update, Delete, and Restore.
Optionally pick fields under Only when these fields change. An update that doesn't touch those fields skips the rule. Leave it empty to react to any change.
Under When, add conditions. Leave it empty and the rule runs on every matching save.
Under Then, set what the rule does. This part depends on the rule type.
Set the Order if several rules of the same type depend on each other.
Make sure Rule is active is on, then click Create rule.

Click AI assistant in the rule editor and describe the rule in your own words, for example "orders over 10,000 need a manager in the approver field". The assistant drafts the rule. Click Load into form, check it, and save.

Restore is separate from Create on purpose. Bringing back an archived record can follow different logic than adding a new one.

Conditions#

A condition decides whether the rule applies to this save. You can combine these kinds:

Condition	Use it to
Field comparison	Compare a field with a value, another field, or the current user.
Field changed	React only when a field's value actually changes, optionally from a specific value or to a specific value.
Status changed to	React when a status field reaches a particular state.
All of…	Group conditions that all have to hold.
Any of…	Group conditions where one is enough.
Not…	Invert whatever is inside.
Rows exist in…	Check that another table has a matching record.
No rows exist in…	Check that another table has no matching record.

Comparisons use operators such as is, is not, is more than, is less than, is at least, is at most, contains, starts with, is one of, is empty, and is not empty.

Values in conditions and actions#

Source	What it gives you
Value	A fixed value you type.
Field	A field on the record, either After the save (the new value) or Before it (the old value).
Context	A fact about the save: the Signed-in user, The user's groups, whether the User owns the organization, The user's permissions, Right now, the Current table, or the Current row.
Row	The whole record, before or after the save. Useful when you start a workflow.

Computations can also use a total from another table or a formula. See Computation.

Manage rules#

Each rule in the list shows a one-line summary of what it does, on which operations, and when. From a rule's menu you can:

Enable or Disable it without deleting it.
Edit it.
Duplicate it. The copy starts disabled so you can adjust it before it runs.
Open its Execution history.
Delete it. It stops running immediately. Records it already wrote stay as they are.

The Execution log tab shows every time rules ran on this table, with the outcome (Passed, Refused, Failed, or Skipped), the operation, how long it took, and a step-by-step trace.

What rules don't do#

Rules don't send email, wait, create PDFs, or call other systems. Those belong in a workflow. A side effect can start a workflow, and the workflow only starts after the save has been committed. It never runs for a save that was rolled back.

Some bulk operations skip business rules for speed, for example the Bulk Upsert DataView step in a workflow. Don't rely on a validation to protect records that arrive that way. Add the checks to the workflow before the write instead.

Business rules aren't available on time series tables. Business rules are included on selected plans. If Business Rules is greyed out in the view settings, your plan doesn't include it.

Plan your rules#

Write each rule as one sentence: on this table, on these operations, if this condition, then this effect. Name the type. Decide what the person sees when a guard or validation refuses the save, and write that message in their words. If one rule depends on another, give them an order, remembering that computations always run before validations, and validations before guards.

ComputationFill a field automatically when a record is saved.ValidationCheck data and show what is wrong.GuardBlock a change based on state or role.Side effectWrite to other tables or start a workflow.