Guide
Validation rules is Pro+ plan feature
Validation Rules in Fibery help keep your data accurate and workflows consistent. They set conditions that must be met when someone updates an entity. If a rule is triggered, the system blocks the change and alerts the user.
A validation rule fires when its condition is true, and it blocks the action. So you're essentially defining "what should NOT be allowed" rather than "what's valid." Some examples:
Do not allow sales probability below 0% or above 100%
Do not allow URLs without linkedin.com
Planned End date should never be before Planned Start date
Main elements of a validation rule:
Trigger: The event or field change that causes the rule to be checked. Create and Update events are supported.
Validation Formula: A condition (expressed as a formula) that must be false for an entity update to succeed.
Warning Text: The message shown to users if the rule is true.
Enable/Disable: Rules can be temporarily turned off without deleting them.
How to add a new validation rule
Enable Architect mode (use Shift + Shift keyword, or click a special icon on top in the left sidebar). Navigate to some Database, find Validation Rules section and click + icon.
Note that validation rules are not available for Integration or User databases.
You have to specify rule name, select fields that trigger the validation, set validation formula and a warning message.
Validation formula is the most complex part of the rule. Here are some advices:
A validation formula can only return true or false. If triggered validation rule returns true then entity update is rejected and a user sees warning message.
Check Formulas guide to see what you can do with formulas language.
In most cases Ask AI to generate action will do the job, so try to use it, just describe the desired validation behavior and check created formula.
Validation rules can be created by workspace Admin, or user with Architect access to the database, rule is created in.
Validation rules and updates
When a user tries to update an entity and validation rule is true, the change will be rejected and a user will see a warning message.
Note that for batch update all entities in the batch should obey validation rules, otherwise all changes will be reverted and no entity will be updated.
Not all changes are done via UI. Note that validation rules are always executed, so if you can receive an error in API call, or an error will be recorded in activity log for automation rule if it attempts to do something that triggers some validation. Even Undo action may not work if validation rule denies it.
If the Validation rule got broken, notification will be sent for two cases:
Create Event specifics
You can run Validation Rules at the moment an entity is created.
❗️ Please use these rules with care. In some cases, users will only be able to create new entities via Forms, since there may be no good way to provide the values required by the validation rule outside of a Form View.
Note that previous fields values are not available for Create triggers (since the entity did not exist before).
Limitations
Maximum of 100 validation rules per workspace is allowed.
Some formula functions and references are not supported (e.g., multi-relations, This).
Examples
Here are some formulas examples for validation rules:
For Feature database:
Planned End date should never be before Planned Start date: [Step 1 Feature].[Planned Dates].Start() >= [Step 1 Feature].[Planned Dates].End()
Ensure Owner is assigned for In Progress Features: [Step 1 Feature].State.Name = "In Progress" and IsEmpty([Step 1 Feature].[Owner]
Ensure Product Area is set for Non-Icebox Features: [Step 1 Feature].State.Name != "Icebox" and IsEmpty([Step 1 Feature].[Product Area]
Ensure no Features are assigned to Abandoned State without justification: [Step 1 Feature].State.Name = Abandoned" and IsEmpty([Step 1 Feature].[Rejection Reason]
For Account database:
Do not allow phone number that is not in specific format (US Style format (123) 456-7890): MatchRegex([Step 1 Account].[Phone], "^\(\d{3}\) \d{3}-\d{4}$") = false
Do not allow URLs without linkedin.com: MatchRegex([Step 1 Account].[LinkedIn URL], "^https?://(www\.)?linkedin\.com/.*$") = false
Do not allow legal address in the wrong format (Basic check for addresses starting with a house number. Can be customised for more complex formats): MatchRegex([Step 1 Account].[LinkedIn URL], "^\d+\s+[a-zA-Z0-9\s,.-]+$") = false
Do not allow sales probability below 0% or above 100%: [Step 1 Account].[Sales Probability] < 0 or [Step 1 Account].[Sales Probability] > 1 Note that 99% in Fibery stored as 0.99, thus you have to use 0..1 scale.
Rules for a user who made the change:
Do not allow change fields for users in Mobile team: [User who triggered Rule].Teams.Filter(Name = "Mobile Team").Count() = 1
Do not allow changes for assigned users, only manager can do it: [User who triggered Rule] != [Step 1 Feature].Manager
Do not allow change for any user, except who created a feature: [User who triggered Rule] != [Step 1 Feature].[Created By]
Do not allow changes for Teddy: [User who triggered Rule].Name != "Teddy"
Do now allow changes for users that are not in Manager role: [User who triggered Rule].[User Role].Name != "Manager" (here we assume that User has a single select User Role)
You can access the previous value of a field when creating validation rules. This means you can enforce workflow transitions and maintain data integrity by validating not just where an entity is going, but where it came from. When setting up a validation rule, you'll see a new variable available: [Step 1 Feature (Previous)] (where "Feature" is your database name). This variable holds the values of the entity before the current change was made. Some examples
Prevent basic status transitions (Open → ❌ Closed): [Step 1 Feature (Previous)].State.Name = "Open" and [Step 1 Feature].State.Name = "Closed"
Prevent status transitions unless certain conditions are met (e.g., a task can't move from "In Progress" to "Done" unless someone is assigned): [Step 1 Feature (Previous)].State.Name = "In Progress" and [Step 1 Feature].State.Name = "Done" and [Step 1 Feature].Assignees.Count() = 0
A project manager wants to restrict the ability to close tasks by other people. Only Teddy should be able to move tasks from 'In Progress' to 'Closed': [Step 1 Feature (Previous)].State.Name = "In Progress" and [Step 1 Feature].State.Name = "Closed" and [User who triggered Rule].Name != "Teddy Bear"