Skip to main content
Die Dreamforce findet vom 17. bis 19. September in San Francisco statt. Registrieren Sie sich jetzt und sparen Sie 20 % mit dem Code DF24TRAIL20

Implement Best Practices

Learning Objectives

After completing this unit, you’ll be able to:

  • Design user-friendly validation rules.
  • Create validation rules that consider existing data.

Make Your Validations User-Friendly

Think of error messages as guideposts that help users navigate your validation rules. Here’s an example of an effective error message for the Amount field. 

When the stage is Qualification or higher, you must enter an amount. [OPP003]

Let’s take a closer look at why this error message works, and what you can do to make your error messages just as effective. 

Make error messages clear.

Error messages should be concise and tell the user exactly what caused the rule to be triggered and what needs to be done to fix the error. In the previous example, we know exactly what stage requires an amount. If you are not ready to put in an amount, you can adjust the stage.

Include a unique error code.

Like the error message above, it’s a good idea to include a unique error code. This error code helps you find the validation rule if a user contacts you asking for help. A good practice is to use a naming convention so you can identify the object. For example, your opportunity validation rules could all begin with OPP and then use a sequential number to identify the individual opportunity validation rules. This is especially helpful because validation rules can fire when rollup or automation update related records. Nothing is more frustrating than spending your time looking at the wrong object in setup!

Choose the error location carefully.

Whenever possible, show the error message on a field. When you display the error message on a field, like in the example above, Salesforce provides a link in the error message that allows the user to quickly jump to the field in question to correct it.

Cover one scenario at a time.

What if you require both Amount and Next Steps to be populated when an opportunity is set to the Qualification stage? It might be tempting to use a single validation rule and check for both fields in your formula. This can lead to frustration from users because your error message can’t tell the user if one or both fields need values. Also, you cannot display your error message on both fields that need attention. Split these two requirements into individual validation rules to make your formula simpler and give better feedback to your users.

Handle Record Changes Gracefully

Business requirements change over time, and you may need to add new validation rules to keep up. Think about the example we used in the last unit: Account numbers must be eight characters long. What if you have existing data with an account number that doesn’t meet this requirement? When a user edits one of these records, they will encounter the error that they need an eight character account number even if they don’t edit the account number. 

This can be a problem, especially if the user doesn’t have permission to edit the account number field! To avoid problems like this, add functions to your validation rule formula to detect if the record is new or if the account number has changed.

Here are a few functions that come in handy for targeting your validation rules to specific scenarios.

  • ISCHANGED(field_name)Returns TRUE when a specific field has changed values. Use this function to selectively fire your validation rules only when the field the rule cares about has changed.
  • ISNEW()Returns TRUE when a record is being created. Typically you want to use ISNEW() whenever you use ISCHANGED. Fields are not detected as changed when the record is being created.
  • PRIORVALUE(field_name)This handy formula lets you see what a value used to be. One use case would be to prevent an Opportunity from being changed from Closed Won. You could check the prior value of the Opportunity Stage. If it is Closed Won and the Stage has been changed, then you can display an error to the user.

Build a Validation Rule That Detects Changes

Ready to create a validation rule that can detect changes? Let’s create a new validation rule that requires the close date to be today or later for new opportunities or opportunities that have a change in the close date. (If you want to see how this works with existing data, ensure you have an opportunity in your Playground with a close date before today before creating this validation rule.)

  1. From Setup, click Object Manager.
  2. Click Opportunity.
  3. In the left sidebar, click Validation Rules.
  4. Click New.
  5. Enter the following properties for your validation rule:
    1. Rule Name: OPP001_Close_Date_After_Today
    2. Description: The close date must be today or later for new opportunities or when the close date is changed.
    3. Error Condition Formula: 
AND(
  OR(
    ISNEW(),
    ISCHANGED(CloseDate)
  ),
  CloseDate<TODAY()
)

d. Error Message: The close date must be today or later [OPP001]

e. Error Location: Field,Close Date

6. Click Save.

Try different scenarios to see how this validation rule works.

  • You should not be able to create a new opportunity with a close date earlier than today.
  • You should not be able to update an opportunity’s close date to yesterday.
  • You should be able to update an opportunity’s close date to today.
  • You should be able to edit other fields on an opportunity with a close date in the past.

Next, let’s discuss how to add bypass switches to your validation rules.

Resources