Side effect rules · Dokumentacja

A side effect runs after the record is stored, as part of the same database transaction. It can create, update, or delete records in another table, or start a workflow. Use it to keep related tables in step: write a history entry when a status changes, update an order when a line changes, create a task when a job is booked.

Create a side effect#

Open any view on the table, click Settings, choose Business Rules, and click New rule.
Enter a Name and set the Rule type to Side effect.
Choose the operations under Runs on, and optionally add conditions under When.
Under What to do, choose Create a row, Update rows, Delete rows, or Start a workflow.
Fill in the settings for that action, described below.
Under If this fails, choose what happens if the action fails.
Click Create rule.

Write to another table#

Create a row: pick the table under In which table, then set each field under Values to set.
Update rows: pick the table, describe Which rows to update, and set the new values.
Delete rows: pick the table and describe Which rows to delete.

Values can be fixed, copied from the record that was saved (before or after the change), or taken from the context, such as the signed-in user or the current time.

Deletes run without asking for confirmation. Keep the filter under Which rows to delete as narrow as possible, for example "Order is this order", so the rule can't remove more than you intend.

If this fails#

Option	What happens
Roll back the whole write	The original save is undone too. Nothing is stored. Use this when the two tables must always agree.
Log it and let the write through	The original save is kept and the failure is recorded in the Execution log. Use this when the extra write is nice to have.

Start a workflow#

Choose Start a workflow when the follow-up needs more than a database write: sending an email, generating a document, calling another system, or waiting for an approval.

Pick the workflow. Workflows that accept a record from this table are listed first, under Accepts a row from this table.
Under Inputs, fill in the workflow's inputs. Use the triggering row passes the saved record.
Under Which view, choose the view the workflow reads the record through. The default is the table's base view.

Once saved, the rule appears in the workflow's Triggers panel under External callers, so whoever edits the workflow can see what starts it.

The workflow starts after the save has been committed, so it can't roll the save back. If the save is rolled back, the workflow never starts. If the follow-up must succeed for the save to count, write it with a create, update, or delete action instead.

Examples#

Side effect	Runs on	When	What to do
Status history	Update	Status changed	Create a row in Status history with the old and new status
Book a follow-up	Create	Type is Installation	Create a row in Tasks for the assigned technician
Clean up lines	Delete	Always	Delete rows in Order lines where Order is this order
Send confirmation	Update	Status changed to Confirmed	Start a workflow that emails the customer

Things to keep in mind#

A side effect that writes to another table can run that table's own rules too. Keep these chains short, and avoid rules that write back and forth between two tables.
If you only need to show a total from related records, a Rollup column is simpler than a side effect that copies the total on every change.
Side effects run after computations, validations, and guards have all passed, so they only run for saves that are allowed.

Business rulesHow the rule types fit together and run.WorkflowsBuild processes that send email, create documents, and more.