Property alerts — confirmation before update
1. What it is
By default a property change is saved as soon as the user confirms the field or clicks outside it. For properties where a change has consequences (automations, status changes, links to third-party systems), an admin can configure an alert: a confirmation modal with a custom title and message that is shown before the change is saved. Properties without alerts behave exactly as before.
2. Where it is configured
Definition settings → Properties → open the property → Alerts tab → Add alert. After Save, the property row shows a bell with the number of alerts; clicking it opens the Alerts tab.
Fig. 1. Alerts tab of a property.
Each alert is a collapsible card with Title and Message (both multilanguage, Message is rich text) and two condition blocks. The counter next to "Alerts" and on the bell shows how many alerts the property has.
Fig. 2. Properties list.
Brand and Model have one alert each (bell with a red counter). Properties without alerts have no bell.
2. 1 CMS (Brand Alert setup)
Fig. 5. CMS table view.
Inline editing of a cell (for example Brand or Model, which have alerts) goes through the same check and opens the confirmation modal.
Not covered: bulk edit, field mapping and import. They write through different endpoints, so no modal is shown there.
3. What an alert contains
Field | Meaning |
|---|---|
Title, Message | Text of the confirmation modal, per language. |
New value | Conditions on the value that is being written right now. |
Record conditions | Conditions on the record as it will be after the save: other properties keep their stored values, the edited one already holds the new value. Can reach into linked records (up to 300 per relation). |
- The alert fires only when both blocks match. Both blocks empty = fires on every change.
- A property can have several alerts. They are checked top to bottom and the first full match is shown. Order is changed by dragging the card.
Fig. 3. Alert with conditions.
This alert fires only when the new value is "Diesel" and the record has Brand and Engine filled in.
Some property types limit what can be filtered in New value:
Property type | What can be filtered in New value |
|---|---|
Computed | Alerts tab is disabled |
Rich text, File | Only is empty / is not empty |
JSON | Not filterable; use Record conditions instead (the UI says so) |
4. Process workflow (Car Alert setup)
Editing works as usual. When the change matches an alert, the modal is shown instead of an immediate save.
Fig. 4. Confirmation modal.
Shown here on a field of a manual task in a process. Title and message come from the alert.
Button | Result |
|---|---|
Save anyway | The value is written. History shows the change. |
Cancel | The change is discarded: no request is sent, the field closes with the previous value (it does not stay in edit mode), nothing is added to History. |
5. Where the confirmation appears
The check sits in the shared property-write layer, so it covers every place where a single property is written
Area | Entry points |
|---|---|
CMS | Record page, inline editing in a table, dragging a card on a kanban board, files (upload, delete, move between properties), restoring a value from History, bulk unlink and bulk delete in a relation table |
Workflows | Manual task fields, process deadline and status, nested fields of related records |
6. Behaviour details
- One action, several writes. One user action can write a property several times: moving a file, for example, is two writes. The alert is asked once per operation per property, not once per write. If files are moved between two properties and both of them have an alert, two modals are shown one after another, one for each property, no matter how many files are moved. Cancel aborts the whole operation.
- Unchanged value. Inline editors skip the save when the value did not change, so no modal appears.
- Mobile. Below 1024 px the modal takes the full width.