A few years into working with Salesforce, I sat in a meeting where a sales leader was furious that the forecast was wrong. We dug in, and the cause was almost insulting in its smallness. Several opportunities had close dates set in the past, sometimes years in the past. Nobody did it on purpose. The form simply allowed it, so eventually someone fat-fingered a date and the numbers quietly went sideways. The fix took about five minutes and cost nothing. It was a validation rule. Let me show you this small superpower.
What a validation rule actually does
A validation rule is a check that runs when someone tries to save a record. If the data breaks a condition you defined, Salesforce refuses to save and shows the user an error message you wrote. That is the whole idea. It is a polite, firm bouncer standing at the door of every record, turning away anything that does not meet your standards.
The beautiful part for a beginner is that this is entirely no-code. You are not writing a program. You are writing a single condition, and Salesforce enforces it everywhere, every time, without you lifting a finger again.
Why bad data is the silent killer
In Fields, Picklists, and Record Types we made the right answer easy by limiting choices. Validation rules go one step further and make the wrong answer impossible to save.
This matters more than beginners expect, because bad data rarely announces itself. A missing phone number, a negative quantity, a close date in the past. None of these throw a dramatic error in the moment. They sit there quietly until a report, a forecast, or an automation trips over them weeks later, far from the scene of the crime. By then nobody remembers who typed what.
Every minute you spend preventing bad data at the point of entry saves you hours of detective work later. The cheapest place to fix a data problem is the instant before it is saved.
The formula mindset
Here is the one mental flip that confuses newcomers, so slow down for it. A validation rule fires when its condition evaluates to true. In other words, you do not describe what good data looks like. You describe what bad data looks like, and when that bad condition is true, the save is blocked.
So instead of “the close date must be today or later,” you write the opposite: “the close date is in the past.” When that statement is true, Salesforce stops the save.
You express that condition as a formula, using fields and functions. For our close-date example, the logic reads naturally:
CloseDate < TODAY()If the close date is earlier than today, this is true, and the rule fires. A user trying to save a past date is stopped and shown your message. A user with a sensible future date sails right through and never even knows the rule exists. That last part is important. A good validation rule is invisible to everyone doing the right thing.
Building it, step by step
You do not need to memorize screens, but the shape of the process is worth knowing:
- Go to the object you want to protect, for example Opportunity, and open its Validation Rules section in Setup.
- Create a new rule and give it a clear name like
Close_Date_Not_In_Past. - Enter the error condition formula, the “what bad looks like” statement.
- Write the error message the user will see, and choose where it appears.
- Save and activate it.
That is genuinely it. From that moment on, no one in the org can save an opportunity with a past close date.
Keep your error messages human
This is the part people rush, and it is the part users actually feel. When a validation rule blocks a save, the only thing standing between a frustrated user and a fixed record is your error message. Make it count.
A weak message says: “Invalid date.” The user stares at it, confused, and pings you on chat.
A strong message says: “The Close Date cannot be in the past. Please choose today’s date or a future date.” Now the user knows exactly what is wrong and exactly what to do. They fix it and move on without ever contacting you.
Think of the message as a tiny note you are leaving for a stranger who is mid-task and slightly stressed. Tell them what happened, and tell them how to make it right. That small kindness scales to thousands of saves.
A word on restraint
Because validation rules are easy and satisfying to create, it is tempting to pile them on until every save feels like running an obstacle course. Resist that. Each rule should defend against a real, meaningful problem. Too many overlapping rules frustrate users and, ironically, push them toward workarounds that create worse data than you started with. Protect what genuinely matters, and let the rest breathe.
There is a parallel to teaching here. The best correction is the smallest one that gets a student back on track without crushing their momentum. One clear, well-placed rule does more good than ten that make people dread hitting save.
Your next step
You have just learned one of the highest-value no-code skills in all of Salesforce. With a single condition, you can keep an entire org’s worth of data honest.
To sharpen the formula mindset you just used, continue with Formula Fields Explained: Calculations Without Code, where the same formula language does calculation instead of enforcement. If picklists and field types still feel shaky, revisit Fields, Picklists, and Record Types. It all lives in Foundations.