Validation rules! Maybe this one helps - Part 1

Validation rules, what a great tool! It probably doesn't make sense to go into detail about what it's used for and when it's good to use them. Instead, I want to focus on a few examples that I've used before and believe they can help you too.

If you're interested in knowing what that fancy console for writing validations is, I wrote about it here (CZE) - Better Salesforce Formula.

First Stage - Opportunity created in the initial phase 

Sometimes it is necessary to ensure that an Opportunity (not just that) is created in the first stage, not in a later stage, and so on. There are several reasons for this, such as forecasting, pipeline, and so on. Validation for this is very straightforward, but it can certainly be helpful. (Thanks, Péťo!)"

Example:

AND(
ISNEW(),
NOT(ISPICKVAL(StageName, "New")))

Phone validation

Yes, it is important to keep the phone number in the format required (e.g., integration to telephony). For the sake of simplicity and to give you an idea of what validation could look like, I have prepared a simple rule that checks for:

• Area code for the Czech Republic (CR) (f.e +420777222333)
• Area code for Slovakia (SK)
• Number prefix
• Number of digits

Example:

AND(
NOT(
REGEX(Phone, "[+][0-9]{3}[0-9]{3}[0-9]{3}[0-9]{3}") &&
(BEGINS(Phone, "+420")||
BEGINS(Phone , "+421")
)))

Specific Cases 

Sometimes you need to apply a rule only to specific users, or you want a certain profile (e.g., an integration profile) to have the ability to bypass this validation. It is possible and not difficult at all.

Specific User

• Perhaps the simplest option is: You want some users to have the ability to bypass the rule, while the majority must meet the condition. 
• Simply add a checkbox to the 'User' object, which you then reflect in the syntax. In our case, we will use the previous example - the phone number."

Example:

AND(
$User.PhoneFormatValidation__c = False,
NOT(
REGEX(Phone, "[+][0-9]{3}[0-9]{3}[0-9]{3}[0-9]{3}") &&
(BEGINS(Phone, "+420")||
BEGINS(Phone , "+421")
)))

User who has the checkbox checked is exempt from the condition and can enter any phone number.

Specific Profile

If it is necessary to enable bypassing the rule at the profile level, it is also possible, and once again, it is easy. Just add one line that specifies the profile. In our case, we want to exclude the "Integration" profile."

Example:

AND(
$User.PhoneFormatValidation__c = False,
NOT($Profile.Name = "Integration"),
NOT(
REGEX(Phone, "[+][0-9]{3}[0-9]{3}[0-9]{3}[0-9]{3}") &&
(BEGINS(Phone, "+420")||
BEGINS(Phone , "+421")
)))

Fill in the reason before closing!

Yes, that's a classic. 

Almost every project has it, and I always writing it, so I'll save it here. Simplified, let's say you have an Opportunity or Case, and before closing it, you need to fill in the reason. Again, this falls into the category of the simplest rules.

AND(
IsWon = False,
IsClosed = True,
ISBLANK(What_Happened__c))

And that's all for today! :-)

I will definitely continue with this because there are countless possibilities and variations on how to utilize validations (for example, in flows or other scenarios).

Do you have any specific requests or would you like to know how a condition should be structured (functionally)? Let me know!