The cheapest moment to fix bad data is before it is saved. Once a wrong value is in the system it gets copied into reports, emails and invoices, and someone has to find it later. A validation rule is a gate at the point of entry: it checks the record and refuses the save until the problem is fixed.
What validation rules usually check
| Kind of check | Example |
|---|---|
| Format | An email must contain a domain; a phone number must have enough digits |
| Required in context | A deal in the Proposal stage or later must have a value and an expected close date |
| Ranges | A discount cannot exceed 15 percent; a close date cannot be in the past when the deal opens |
| Consistency | A lost deal must have a lost reason |
| Allowed values | A region must be one of the regions you actually cover |
The best rules encode a standard your team already agrees on but forgets under pressure.
Writing a good validation message
The message is half the rule. “Invalid input” teaches nothing. “Add a domain to the email, like name@example.com” fixes the problem in one go. Say what is wrong and how to put it right, in the user’s language.
When rules should run
Most rules should run whenever a record is created or edited. Some only make sense at one moment, for example on creation only, so that older records are not suddenly unsaveable. Some teams also run rules manually across existing records to find problems without blocking anyone.
Common mistakes
- Too many rules at once. Switching on twenty rules on day one frustrates everyone. Start with the two or three that cause the most rework.
- Rules that block legitimate edge cases. If a rule fires on genuine exceptions, people find workarounds. Leave room, or flag rather than block.
- Rules nobody owns. When the business changes, the rules should change too. Give each one an owner.
- Assuming rules clean old data. Validation stops new problems. Existing records need a separate review.
Validation versus other rules
Validation says “no”. Enrichment fills in a value for you, and duplicate rules look for a record that already exists. Together they form the core of good CRM data hygiene.
How GuardenerAI handles it
- Validation rules in GuardenerAI Automation are written as decision tables in a visual editor, and each rule keeps numbered versions.
- Rules run on create, on edit, on both, or only when you run them by hand.
- They apply to persons, companies, leads, opportunities, opportunity line items, tasks, cases, meetings and invoices. Custom objects use per-field validation such as lengths, patterns and ranges instead.
- A failed rule shows its message at the field, so the person saving knows exactly what to fix.
- CSV imports save records directly and do not pass through save-time rules, so clean a file before importing it. See the CRM page for import details.