Skip to content

Set before save rule – write a field on every save

A set before save rule writes a field immediately before the record is written to the database, on every save. This page describes its settings and behaviour. It is intended for administrators who configure business rules.

1. At a glance
Purpose Sets a field to a computed value each time the record is saved
Typical use "Last changed by", "Last changed at", normalised values (for example an e-mail address in lower case), search keys
Related Default value rule (once on creation), Calculation rule (while editing)

2. Settings

Setting Meaning Default / required
"Field" The field that receives the value required
"Value" The expression that computes the value. It is evaluated against the record that is about to be saved. required
"Ignore business logic" The value is written directly into the field, without validation and without starting calculation rules or event based rules off
"Disabled" The rule does not run off

Plus "Display Name", "Description" and "Tags" (see Business rules).

3. Behaviour

  • The rule runs on every save, for new and for existing records, also when nothing else was changed.
  • It runs late in the save: after the Before Save UI actions, after the check of required fields and after related records were saved – immediately before the record is written (see Business rules, section 3). The value is saved with the record in the same step.
  • Its field can be required. A required field that an active set before save rule fills is not checked with the other required fields, but right after the rule ran. The value the rule writes satisfies the requirement, and the form does not highlight the field as missing. If the rule leaves the field empty – the expression returns nothing, or the user may not edit the field – the save is refused with the usual message for required fields.
  • Without "Ignore business logic", writing the value is a normal field change. Validation rules check it – a rejected value is not set and the field keeps its previous value – and it can start calculation rules, On Change UI actions and event based background action rules. Background action rules triggered here run after this save.
  • With "Ignore business logic", the value is written as it is. Nothing checks it, nothing reacts to it. Use this when the write must not start a chain of rules – and keep in mind that it also skips the validations you may rely on.
  • Several set before save rules of one entity run in no defined order.
  • A rule without "Field" or "Value", or with an expression that no longer exists, does nothing. The reason is written to the application log.

4. Examples

Audit fields. Entity Contract, two rules: "Field" = Changed by, "Value" = the id of the current user; "Field" = Changed at, "Value" = the current server time (UTC). Both have "Ignore business logic" on, so the stamp does not start any follow-up rules.

Normalised e-mail address. Entity Contact, "Field" = E-mail, "Value" = E-mail in lower case. A user who types Anna.Berg@Example.com saves anna.berg@example.com.

5. Limitations

  • If the rule leaves a required field empty, the save is refused only after related records that are saved together with the record and attached files were stored. The record itself is not written.
  • A value that a validation rule rejects is dropped without a message – the save still succeeds with the previous value.
  • No order between several set before save rules.