Bad data has always been just that – bad. It’s frustrating, unreliable, and time-consuming to fix. But now that we’re in an era that focuses largely on AI and automation, it’s become a real barrier.
Flows, Agentforce, or even Einstein features can give you so much power when it comes to smarter decisions and powerful automations. However, they all rely on the same thing: your data. And because of that, the quality of their results will depend almost entirely on the quality of your data. Even small mistakes like poorly formatted numbers or unrealistic amounts can break reports and disrupt automations.
The good news is that many of the most common data issues can be prevented with simple validation rules. In this article, we’ll look at seven validation rules that take only a few minutes to implement but can dramatically improve the reliability of your data.
1. Prevent Dates from Being Set in the Future
Future dates can quietly cause major reporting and automation issues. For example, a Case Close Date or Opportunity Close Date accidentally set in the future can distort pipeline reports and forecasting dashboards. A simple validation rule can prevent users from entering dates beyond today where they shouldn’t exist.
Example formula:
CloseDate > TODAY()
This rule ensures that the date entered is not later than the current day. You can use this on other Date fields. Small protections like this help maintain reporting accuracy across dashboards as well as time-based automations.
Bonus: Use NOW() if you are working with Date/Time fields. For example, RequestDateTime__c < NOW() evaluates the exact current date and time, so it’s more suitable for fields that store timestamps. A common example is preventing event times from being scheduled in the past unintentionally.
2. Require Key Fields Based on Criteria
Yes, and you’re probably thinking, “Why not just make the field required?”. The reason is that setting a field as required is a stricter, always-on requirement, while validation rules allow you to enforce requirements only when certain criteria are met.
One example scenario: it’s easy for busy sales team members to move an Opportunity to Closed Won while forgetting to complete all the fields needed for reporting or the next process. An opportunity might be marked as Closed Won even though an important field like Amount is still blank.
Validation rules can enforce the completion of important fields when an Opportunity reaches a specific stage.
Example formula:
AND(
ISPICKVAL(StageName, "Closed Won"),
ISBLANK(Amount)
)
This sample formula can be used to require values in certain fields for other Objects apart from Opportunities as well. Another common example would be to require a Closed Lost Reason for Opportunities that are Closed Lost.
3. Prevent Edits Based on Criteria
This is commonly used for situations wherein historical data is finalized. A good example is once an Opportunity is closed. Users can sometimes edit these records later, intentionally or accidentally, which can compromise reporting.
A validation rule can prevent modifications to closed deals while still allowing administrators to make necessary corrections.
Adding on to the formula we had in the previous item:
AND(
ISPICKVAL(StageName, "Closed Won"),
ISBLANK(Amount),
ISCHANGED(StageName)
)
The addition of ISCHANGED prevents the rule from firing when someone edits the stage of an already Closed Won record later. Tweaking the formula further:
AND(
OR(
ISPICKVAL(StageName, "Closed Won"),
ISPICKVAL(StageName, "Closed Lost")
),
NOT($Profile.Name = "System Administrator"),
ISCHANGED(StageName)
)
This rule blocks changes to the stage in Opportunities that have already been closed (either won or lost) unless the user is an administrator. You can customize this further by adding more fields that you don’t want to change/trigger the rule.
4. Prevent Negative or Unrealistic Values
Numeric fields are especially prone to accidental data entry mistakes. Users can unintentionally add extra zeros, enter negative numbers, or even input values that simply don’t make sense for the business.
For example, an Opportunity Amount might be entered as -5000 or 500000000. Validation rules can prevent unrealistic values from being saved and protect the accuracy of forecasts and reports.
A (very) simple sample formula is:
Amount < 0
Insanely simple, right? But it does the job of preventing negative values, like in Currency fields:
Formulas can go beyond just restricting outrageous values. You can also expand this idea to enforce reasonable limits (depending on your business), like:
OR(
Amount < 0,
Amount > 10000000
)
5. Enforce Data Consistency Between Related Fields
Sometimes, fields should logically match or follow certain relationships. When they don’t, reporting and automation can behave unpredictably, or results can end up not making sense.
For example, if an Opportunity has a Contract Start Date, that date should not occur before the Opportunity’s Close Date. What contract starts before an Opportunity is even closed in the first place?
An example formula would be:
Contract_Start_Date__c < CloseDate
Again, simple! And also similar to the first item in this article with TODAY() and NOW(), except this time we’re validating the relationship between two fields instead of comparing against the current date.
You can also use this within a formula that enforces specific criteria. For example, you may only want to enforce this once the Opportunity is Closed Won:
AND(
ISPICKVAL(StageName, "Closed Won"),
Contract_Start_Date__c < CloseDate
)
This ensures that the contract start date is only validated when the deal is finalized.
6. Enforce Multi-Field Dependency (At Least One Required)
We talked about requiring key fields in the second item. But sometimes, it’s not about just making a single field required, but more about ensuring that at least one of several fields is populated.
A simple but common example can be made with the Contact object. More often than not, a Contact should have at least one way to be reached, and that can be provided by either an email address or a phone number. Making both phone and email required at the config level would be too strict, but leaving both optional creates the possibility of incomplete records.
Validation rules give you just the right amount of flexibility for requirements like this. Example formula:
AND(
ISBLANK(Email),
ISBLANK(Phone)
)
This prevents the record from being saved unless at least one contact method is provided.
7. Enforce Mutually Exclusive Fields (Only One Can Be Selected)
This is similar to the previous item, but this time, it restricts fields that shouldn’t be populated at the same time. Let’s illustrate this better with an example.
An Opportunity might have two checkbox fields: New Business and Existing Customer.
Neither can logically be true at the same time, but without enforcement, users can easily select both. Here’s an example formula to solve this:
AND(
New_Business__c = TRUE,
Existing_Customer_Upsell__c = TRUE
)
This prevents both checkboxes from being selected simultaneously.
Final Thoughts: AI-Ready Data Starts With the Right Approach
At this point, it’s clear that validation rules are powerful. But in today’s world, where Salesforce is pushing for more and more AI integrated into the platform, they’re only one piece of the puzzle. And as with any other Salesforce features, there are often multiple ways to enforce the same behavior. At the end of the day, choosing the right tool still comes down to good architectural decisions.
Take item seven above as an example. We used a validation rule to prevent two checkbox fields from being selected at the same time. While this works, a more ideal approach might be to replace those checkboxes with a single picklist field instead. This removes the possibility of invalid combinations entirely, rather than reacting to them after the fact.
But on the other hand, if you’re working in an org that has used these checkboxes for a significant amount of time, replacing a field is not as easy as it sounds. The validation rule will still come in handy, especially for preventing future mistakes.
This distinction becomes even more important when working with AI and automation. Tools like Flow and Agentforce don’t just rely on data being present, as they rely more on data being structured, consistent, and predictable. The simplest way to achieve this is by designing your data model so that bad data is difficult to enter in the first place. It’s one of the most effective steps you can take toward successful AI adoption (and it doesn’t even require something like Data Cloud/Data 360 to get started).
