It’s very easy to use validation rules (or VR). This can lead each consultant to create too many. If the Salesforce platform allows that, their multiplication can be a pitfall to be avoided for the good of the project.

Reminder on Validation Rules

Validation Rules are one of the flagship features in the Salesforce platform. Very practical, they contribute to the quality of the data by preventing user input if certain business rules are not respected. When a new Salesforce customer learns more about the platform, it takes very little time to understand the usefulness of this feature. And he can put all his heart into wanting to implement a multitude of VR in his Salesforce organization.

In addition to the practicality of this feature, it is important to be vigilant and create them with measure. Indeed, these VR are often implemented from the start of the project during the customization phase. Then day after day, some of them may require modifications or may also show side effects.

Some risks of VR multiplication

Most validation rules use short formulas. Their modifications are easy in themselves. However, if the number of RVs is large and in their formula a field, which the client decides to delete, is referenced, the consultant will have to modify all the involved RVs. This can take time and does not add much value.

If the consultant has factored his RVs into only a few, the formulas will be important (within the limit of 3900 characters). And precisely, finding the elements of the formula to be removed and modifying the formula accordingly will require more time.

Finally, you may end up with side effects that will increase your project load.

VR and Lead conversion

For example, you put 3 VR on the Account object, 2 on the Contact object and 5 on the Opportunity object, for a total of 10. Your client wishes to use the Lead Conversion feature to create an account, a contact and optionally an opportunity. He also wants these 10 fields to be mapped. In this case, setting up these 10 VRs on the Lead object is a requirement.

VR and third-party system

Another example. You set up an interface with a third-party system (ERP, business application). In the business need, this third-party system must be able to create accounts, contacts and opportunities. In this case, it will be necessary to ensure that the third-party system sends all the information to Salesforce, otherwise the creations will be blocked. In fact, there will be an additional project charge for the customer or for the service provider in charge of the maintenance of the third-party tool.

VR and Data migration

Last, but not least. The initial data load is a critical point for user adoption. You have warned your client that the fields subject to VR must be completed in the source. But when you receive the import files, this is not the case. Notifying your client, the latter explains to you that he could not do better and that you have his agreement to deactivate the RVs before import and then reactivate them after import. Depending on the number of RVs in place, you consume the project load.

Conclusion

VR are a wonderful tool to prevent users saving invalid data. But more is not always good.

It’s up to you to be vigilant and take all the necessary precautions.