Automate, don’t validate. It’s a rule we’ve mentioned before, in our 11 tips to boost user productivity. After all, every automation rule you build speeds up your users’ work. Each validation, meanwhile, slows them down.
We understand, though, that it can be challenging to put this abstract concept into practice. So, in this blog, we’ll walk through one specific way to do so, building Salesforce automations that act like validation rules. These “hybrid” rules serve as jacks-of-all-trades in particular use cases, keeping your data clean while saving your users time. Everyone wins.
Interested in learning more? Let’s jump in.
{{cta('a7beaa7e-be12-44e5-ae0a-c147f5a83e98')}}
When to Use Validations, Automations and Our New Hybrid Rules
Before we get into the weeds, let’s cover some best practices around when to use different types of rules: validations, regular automations and automations that act like validations.
Validation Rules: As a rule of thumb, you should only use validation rules when you want to prevent the wrong data from being entered, but you (the admin) can’t specify what the right data should be. A classic example is the “NOT(ISBLANK())” scenario: At a certain point, the data must be there, but it’s up to the user to say what that data is.
Automations: The use case for your standard automations (workflows, processes and flows alike) is the opposite: You, as the admin, can pull data into a field, but it’s just a suggestion. The user keeps the ability to override that automation if they wish.
Automations that Act Like Validations: And here’s where our hybrid automation comes into play: when you need to lock down what the user can enter in a field, and you can specify (as the admin) what information should go in there. You need an automation that not only correctly inserts the right value, but also prevents the user from changing this value after that. You need an automation written like a validation rule.
Let’s take a look at a couple of examples that show why this solution works better than the alternatives.
Example 1: When an Opportunity Involves a Standard Contract, Payment Terms Must Be “Net 15”
Both of the examples we’ll examine are on the opportunity. The first is relatively simple: When the “Standard Contract” checkbox is checked, the payment terms must be “Net 15.” No exceptions. Let’s take a look at how we might solve this with a standard validation or automation rule and why our hybrid rule is the way to go:
Validation Rule: You could easily build a validation rule that solves part of this problem. Its criteria would look something like:
But this will only prevent the user from moving forward until they manually select “Net 15.” That’ll frustrate your co-workers in no time. So, you’ll naturally consider an automation instead.
Automation Rule: Here, an automation sounds like the right call. With some simple logic, you can build a process criteria node that looks like this:
From there, the corresponding action sets the Payment Terms to “Net 15.” Problem solved, right? Not exactly. Because what if the user changes the payment terms after the automation runs? You can’t make the field uneditable, because you need the user to select the payment terms manually when the opportunity doesn’t involve a standard contract.
And things get complicated if you have other validation rules on the Payment Terms field (like, if the field must be filled out by a certain stage). Since Salesforce evaluates validation rules before running automations, you’ll have to carve exceptions out of any validations involving this field, to allow for situations when you’ve recently checked the “Standard Contract” checkbox. You’ll end up with a messy array of automations and validations smashed together in an ill-fitting puzzle. Trust me — I’m speaking from experience.
The Hybrid Automation: That’s why I suggest our solution: an automation written like a validation rule. Still using process builder, let’s write the criteria slightly differently:
The resulting action is the same — Payment Terms equals “Net 15” — but if you compare this automation to the validation rule written above, you’ll notice that the criteria are identical. So, from the user’s perspective, not only will the Payment Terms automatically fill in when they mark that the opportunity involves a standard contract; this rule will also automatically correct their mistake when they try to change the payment terms to anything besides “Net 15” under these conditions.
That’s what I mean by writing an automation like a validation rule. When you set a process like this, it fires every time a validation rule would, but instead of stopping the user in their tracks, it gives them the answer they need to move forward.
Example 2: A Managed Services Amendment Must Have the Same Monthly Rate as Its Parent Opportunity
Here’s a more advanced example. I was once faced with a business problem with these requirements:
- Salespeople are allowed to create amendments (a record type of opportunities) for managed services projects.
- But these amendments can only extend the length of the contract. The number of hours per month and the bill rate (dollars per hour) must remain the same as the original opportunity to prevent invoicing errors.
- The monthly hours and bill rate aren’t set on the amendment itself — they’re calculated from the totals of the amendment opportunity’s line items. The correct solution needs to control how the user interacts with the line items, as well as the amendment itself.
How could I best solve this use case for my team?
I realized that I couldn’t solve this problem with a validation rule. It would have stopped sales reps from entering the wrong data but wouldn’t have told them the specific right answer they needed. It would’ve forced the reps into a lot of mental math and even prevented them from making certain changes without following a cumbersome order of operations, drastically slowing their work.
A standard automation rule would have run into other problems. This type of solution can give the rep the right answer once, but it can’t correct the data if the salesperson adjusts the number of months on the amendment opportunity or manually alters its line items. It would’ve created the possibility for bad data.
Then it hit me. I needed to write an automation like a validation rule. Here’s what I ended up with:
It looks like a lot, I know. But to put the criteria in plain English, for any managed services amendment, once the contract length is filled in, it checks that the monthly hours and monthly rate (in dollars) are the same as those on the amendment’s parent opportunity. If either doesn’t line up, it fires this flow:
The flow deletes all existing line items on the amendment (if any exist) and then inserts one line item with the correct dollars, hours and months to match the new contract length and the original opportunity’s bill rate and monthly hours.
From the user perspective, it looks like this.
- As soon as they enter the length of the amendment (in months), it automatically creates a line item with the accurate number of dollars and hours.
- Change the number of months, and the rule correctly adjusts the dollar and hour values to keep the same rate.
- If the rep tries to delete, add or change the amendment’s line items in a way that throws these rates out of alignment, the rule automatically overwrites these incorrect edits.
So, no matter what the rep does, the amendment stays in line with the rates on the original opportunity.
Hopefully, these examples highlight the power of these rules. When needed, they not only save your users time and energy — they also keep your data clean. They serve the function of two rules at once, making your technology and entire company more efficient as a result.
Interested in more tips to streamline your CRM processes? Check out our eBook on how your Salesforce strategy might be killing user productivity. It’s chock full of best practices and real-life examples to guide your teams toward higher efficiency.
