Validation Rule

A validation rule is a piece of Salesforce configuration that checks a record's data at the moment it is saved and, if a condition you define is met, prevents the save and displays an error message. It makes sure the information entering the system follows your business rules before it is stored.

The logic is written as a formula that returns true or false: when it returns true, Salesforce treats the data as invalid and blocks the operation. For example, a rule can require the "Amount" field to be greater than zero, a phone number to have the right format, or an Opportunity not to be marked as won without a close date. It is one of the most widely used declarative (no-code) tools in Salesforce for maintaining data quality.

Unlike a required field, which only demands that a value exists, a validation rule can check complex relationships across several fields and apply conditional criteria based on the record's context.

How it works under the hood

A validation rule is defined on an object (Account, Opportunity, Case, a custom object, etc.) and has three parts: a condition formula that returns true or false, a user-friendly error message, and the error location (at the top of the page or next to a specific field). Salesforce evaluates the formula every time someone tries to save a record, whether from the user interface, a bulk load, an API or an automation. If the formula returns true, the save is canceled entirely and the user sees the message; if it returns false, the record is saved normally.

The key detail is that the condition is written the opposite way from what intuition suggests: the formula describes the unwanted state. If you want to make sure a discount never exceeds 30%, the condition is `Discount__c > 0.30`. When that expression is true, the data is invalid and the save is blocked. Rules use functions such as `ISBLANK`, `ISPICKVAL`, `ISCHANGED`, `PRIORVALUE`, `REGEX` and logical operators to build sophisticated criteria.

Why it matters for the business

The value of a validation rule is that it moves quality control to the point where data enters the system, instead of discovering errors later in reports or in a broken integration. Dirty data, such as zero amounts, inconsistent sales stages or documents with no tax ID (CUIT), contaminates dashboards, automations and the sales forecast. A well-designed rule prevents that problem without writing a single line of code and without relying on the team's manual discipline. That is why it is a core piece of data governance and consistency in the CRM.

A concrete example in Argentina

A consumer goods distributor in Buenos Aires uses Salesforce to log Opportunities. The sales team sometimes marked deals as "Closed Won" without entering the customer's purchase order number, which broke invoicing further down the line. The administrator created a validation rule with the condition `AND(ISPICKVAL(StageName, "Closed Won"), ISBLANK(Purchase_Order__c))` and the message "You cannot close the deal without entering the customer's purchase order". Since then, no Opportunity reaches invoicing without that information, and the back office stopped chasing sales reps for missing data.

Common mistakes when implementing them

• Inverting the logic: writing the condition to describe valid data instead of invalid data makes the rule block always or never.
• Blocking bulk loads and integrations: an overly strict rule can stop data imports or API syncs that load legitimate but incomplete records.
• Cryptic error messages: a text like "Validation error 23" frustrates the user; the message should say what to fix.
• Too many overlapping rules: piling up dozens of undocumented rules makes it impossible to know why a record will not save.
• Not accounting for existing records: activating a new rule can prevent editing old records that already violated the condition; it is a good idea to use `ISCHANGED` or `ISNEW` to narrow its scope.

How it differs from other tools

It is easy to confuse a validation rule with other declarative Salesforce mechanisms. The difference lies in when each one acts and what it is for.

As a rule of thumb, validation is the first choice when the goal is simply to prevent incorrect data: it is declarative, quick to create and easy to audit. When the logic goes beyond what a formula can express, or needs to look up other records, you turn to a Flow or to Apex. Knowing how to pick the right tool is part of the craft of a good Salesforce administrator.