Validation rules

Description

Pro plan feature.

Problems

Enforcement of Workflow Rules and Transitions: Users need the ability to enforce workflow rules and ensure that certain states or transitions are only possible under specific conditions or by certain roles. If conditions aren't met, the transition should be blocked or a notification should be triggered.
Validation of Unique and Formatted Data: There is a requirement for ensuring data uniqueness and correct formatting within fields, such as unique identifiers or specific text patterns (e.g., zip codes).
Process Automation and Conditional Logic: Users require automation capabilities that allow for conditional logic, such as actions triggered by unmet conditions or validation failures (e.g., blocking actions, sending alerts).

Solution

https://www.figma.com/design/1chwiiNz2InYgWAp1Po5WX/PA---Automations?node-id=1227-14942&t=nJ8aiv6Voz58ryH1-1

From UI perspective, we will add Validations sections inside Database menu.

Screenshot 2025-12-12 at 10.30.50 AM.png

It will have a collection of validation rules that will be executed on entity save attempt and throw a warning toast in when needed (🦄 in the better future we may even prevent actions on UI based on validation rules).

Who can create Validation rules?

Architectors and Admins

What databases have Validation rule tab:

❌ Do not show it in Integration database
❌ User database
✅ available in Highlight DB

Every Validation Rule has

Name
Enable/Disable - we should have an option to disable rule without deleting it
Warning text (what will user see in case this rule is triggered and returned true)
Triggers
- Updated (in the future may extend to Created and Deleted), so hardcoded now
- Changed field
  - 1 field is required (user can select several fields, as OR)
  - Supported fields types:
    - Basic fields
    - Relations (reference, to-one)
      - Exclude fields that are set via auto-rule
    - Single-select
  - ❌ Unsupported fields types
    - Lookups
    - Formulas (including Name if it is set via formula)
      - If Name changed to Name generated via formula → Disable automation rule
    - Multi-selects
    - Rich-text fields and snippets
    - Multi-relations
    - Fields that are set via auto-linker
    - Collections
    - Modification Date, Creation Date, Created by
Validation rule as a Formula with boolean outcome. Just a text area with formula.

How validation rules are applied:

😅 Common rule: if validation rule fails — no changes in database.

(Error - text in validation rule + link to the rule itself is a user has access to the rule)

UI including DnD - show toast with error
Change dependency on Gantt Chart → show error and move system to previous state
Integrations - nothing, since we disabled Validation rules for integration databases
Rules - show error in activity log for rule
API - show error
What to do with the batch update → revert the whole transaction if validation for at least 1 entity fails and show error to client
Import to existed database → now the whole import fails if validation for at least 1 entity fails + notification about failed import + error pop-up from validation rule for user
Merge entities, Duplicate entities, Convert → do not allow, show error
AI Agent - show error
❗️ Undo may not work if validation rule denies it (we may decide to allow it, TBD)

When field is deleted

Show [Deleted Field] in red in fields selector or in formula
Disable rule

When formula becomes invalid

Show error in formula
Disable rule

When rule is OK but action is long and rule fails by timeout

User see error ("rule halted by timeout, nothing can be saved, contact Fibery admin to fix it")
Do nothing, what to do?
- Admin can disable rule and contact us

Delete rule

Tech details

Pro plan

workspace has entityValidationRules workspace capability:

Action	with capability	no capability
Create rule	:kot-checkmark:	:kot-cross:
Read rule	:kot-checkmark:	:kot-checkmark:
Update rule	:kot-checkmark:	:kot-cross:
Delete rule	:kot-checkmark:	:kot-cross:

Permissions

i propose to allow create/update/delete validation rules for admins only for now, i.e. no space/db access templates or capabilities for now.

Will implement capability-based access as next step, pure incremental stuff.

Action	Admin	Non-admin
Create rule	:kot-checkmark:	:kot-cross:
Read rule	:kot-checkmark:	:kot-checkmark:
Update rule	:kot-checkmark:	:kot-cross:
Delete rule	:kot-checkmark:	:kot-cross:

Rules max count

Defined 100 as max count of all validation rules in the workspace just to define _any_ upper bound.

Not supported in validation rule's formula

multi-relation fields
THIS reference
using TRIGGERED_ENTITY _within_ Filter(), Sort(), First(), Last()
~~using CURRENT_USER anywhere~~
~~Now()~~
~~Today()~~

Today/Now functions (IMPLEMENTED)

Formula params may have keys with names:

$formula-today-date-placeholder
$formula-now-date-time-placeholder

In that case values in params will also be "$formula-today-date-placeholder"/"$formula-now-date-time-placeholder". So just placeholders.

Backend (core in this case) is responsible for replacing those placeholders with actual values on the moment of rule's execution.

We need to replace them with current UTC date with/without time.

Examples

1.)

{
  expression: [
    ">",
    ["triggeredEntity", "cd363322-c15a-41e4-9a99-69825cdc22b7"],
    ["q/date", "$formula-today-date-placeholder"],
  ],
  params: {
    "$formula-today-date-placeholder": "$formula-today-date-placeholder",
  },
}

should be transformed during execution to

{
  expression: [
    ">",
    ["triggeredEntity", "cd363322-c15a-41e4-9a99-69825cdc22b7"],
    ["q/date", "$formula-today-date-placeholder"],
  ],
  params: {
    "$formula-today-date-placeholder": "2026-01-13",
  },
}

2.)

{
  expression: [
    ">",
    ["triggeredEntity", "cd363322-c15a-41e4-9a99-69825cdc22b7"],
    ["q/date-time", "$formula-now-date-time-placeholder"],
  ],
  params: {
    "$formula-now-date-time-placeholder": "$formula-now-date-time-placeholder",
  },
}

should be transformed during execution to

{
  expression: [
    ">",
    ["triggeredEntity", "cd363322-c15a-41e4-9a99-69825cdc22b7"],
    ["q/date-time", "$formula-now-date-time-placeholder"],
  ],
  params: {
    "$formula-now-date-time-placeholder": "2026-01-13T15:21:06.473Z",
  },
}

Deletion cases

if db is hard deleted then its validation rules are deleted
if db is soft deleted then its validation rules are disabled
if db is restored then its validation rules are disabled
if field hard/soft deleted and it participates in Updated Fields/Validation rule body then validation rule is disabled + notification about disabled rule is sent to all Architect (on Space/Db level) (Works the same in Rules/Buttons)
if field is restored and it participates in Updated Fields/ Validation rule body then validation rules is still disabled (Works the same in Rules/Buttons as they are stay disabled in that case)

References

Guys from Targetprocess are implementing this currently (Q1 2022):

https://www.ibm.com/docs/en/targetprocess/tp-dev-hub/saas?topic=rules-validation

https://www.ibm.com/docs/en/targetprocess/tp-dev-hub/saas?topic=rules-examples

rules1.pdf

rules2.pdf

Notes for QA

Validation rules guide

List of places, where I've added special toast, like in design:

restore
batch-edit units
rename axis
new axis item
create entity on canvas
edit all units (dates, location, reference, etc etc.)
convert
duplicate
creation via form (2 cases, public form and in-app form)
grid set parent
grid clipboard
grid change cell
list/grid dnd
link/unlink on collection-list
entity title
rich-text create new entity via mention or smth
search create new entity
timeline create/update/move card
left menu dnd (smart folder included)

Some places for "Create" trigger are definitely missing here, but let's find them out after we add "create" trigger. It's hard to test without it.