When to use (and avoid) Salesforce validation rules
When to use (and avoid) Salesforce validation rules
We all want quality data in Salesforce. But what's the best way to get it without being annoying? Flows and validation rules both have a role. Read: Everything Starts Out Looking Like a Toy" #213
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: amazing drawings, done only with a pencil. This is a portrait of incredible detail that’s possible through focus and attention. Edition 213 of this newsletter is here - it’s August 26, 2024.
If you have a comment or are interested in sponsoring, hit reply.
The Big Idea
A short long-form essay about data things
⚙️ When to use (and avoid) Salesforce validation rules
As an operator, you always balance the need for correct data on input compared to a process that will automatically remediate that data after the fact. When you administer Salesforce, this is particularly important because some methods to stop input prevent the record from being saved, while other methods allow record completion.
The last thing you want to do typically is to slow salespeople down, but sometimes you need them to enter data in a specific format or within a range. For that purpose, Salesforce validation rules can be very effective. For other processes, especially those handled by automation, using Flows lets you tag or fix a record while allowing the overall process to continue.
Why use a validation rule?
Validation rules let you create a Salesforce formula to prevent the record from being saved if the rule evaluates to true.
A simple example forces the value of a field to be between 10 and 100.
OR(
Your_Field__c < 10,
Your_Field__c > 100
)
Validation rules are typically focused on a single field or a combination of values in multiple fields and prevent the record from being saved when it’s in that state. You’ll want to use this method when you need a rep to enter a value (e.g. a description for a special type of discount).
Flows can fix the value after the fact
It turns out that Salesforce Flows have become a pretty sophisticated alternative to using validation rules to stop the save on a record. With Flows, you can check before a record is saved or after it’s saved to validate a condition like the one above. This lets you fill in a default value if the user has neglected to add one or look up the result of another search to populate a field.
Flows also let you continue to save the record even when it’s in a state that would otherwise trip a validation rule. You can use a Flow to write an error condition to a field and build a list view of records and their error conditions to let operators fix values in batches without slowing the team down.
Another common issue with validation rules is how they stop automated processes from continuing. If you’re using Fivetran, Hightouch, Zapier, or similar to update a row in Salesforce, you want your update to be successful. You don’t want your save blocked by a validation rule that cannot be fixed during the transaction.
Flows give you more flexibility overall, but they require a bit more overhead to get started.
Consider the user when building automation
The primary consumer for validation rules is the user. As an operator, the goal is to remind them what they need to do to move forward. If you’re stopping them from doing their job and delivering an unclear message, your validation rule really isn’t helping.
One way you can miss easily is when you try to put constraints on a date field, for example when you need to validate that a date field is not blank and also is within a certain range (e.g. close date + 60 days for a follow-up task).
Validation rules stop the field from being blank, but in a quirk of Salesforce rules, you can’t build a validation rule that enforces non-blankness and a calculation on the date value.
For that, you need a combination of a validation rule and a flow:
a validation rule to prevent the date field from being blank along with a message suggesting the value to be entered into the field
a flow that checks the resulting value and sets a valid value to continue
The goal? Let the user continue without a nag screen after entering something, and fix the issue if they enter a bogus value just to continue. It also protects records handle by automation from erroring.
What’s the takeaway? Balancing data validation between validation rules (which stop you in your tracks and force you to update) and flows (which can fix the issue automatically). Focusing on the user experience will help you to know the right combination of features to use.
Links for Reading and Sharing
These are links that caught my 👀
1/ An elegy to early computers - The living computer museum – a great resource of the beginning of personal computing – is set to be sold. This collection of Paul Allen’s memorabilia was available to the public and reminded us how swiftly we’ve moved from “luggable” computers to Dick Tracy-style watches.
2/ Context is king - Data is more about just the data (it was always that way). Here’s a thought-provoking post about the need to understand that context before you store or retrieve data.
3/ Saving time - Jason Cohen on doing fewer low-velocity things to get better impact.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want to book a discovery call to talk about how we can work together?
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon