by Alekhya Mandadi

I was doing a deployment, and I came across what I usually recommend to folks in our Salesforce ecosystem.

Here’s the scenario:

Business asks for any or all of the following for better data quality:

1. New validation rule

2. Add a lookup filter on an existing field

3. New required fields or existing fields that were previously not required but now business wants to require them

These are not really complex or unreasonable asks—they happen all the time. And that’s also the beauty of Salesforce in that you can quickly check your work, and then you are well on your way.

One thing I’ve noticed is that people recreate these seemingly simple changes in production to avoid the hassle of going through deployment. This is a big problem because you are kicking the problem can down the road for someone to deal with it.

Next thing, apex classes don’t run when you do a non-code deployment. So, even if you were good about developing your validation rules, required fields in the sandbox, and promote to prod, if your test classes don’t run, you walk away with a false sense of happiness that all is well with your org.

But then comes deployment with Apex!

If the org has Apex classes (which in most enterprise and higher versions, you will come across code) and you are deploying Apex classes, what this could mean is your Apex test classes will start failing as the test classes haven’t been refactored for the new validation rules, lookup filters or required fields.

What should you do?

1. The right thing to do is to always run test classes prior to deployment, whether you are deploying code or not.

2. Validate your change set early. There is a chrome extension – Change set helper that can help validate your change set before deploying to prod. Another way is to deploy the change set and then validate it before deploying. Of course, if you have tools like Gearset, please use them at your disposal to validate before deploying.

3. If you are under a time crunch and you have to get your change set across the finish line, find out the offending items and document them. There is always that lingering question for existing orgs: “Why must I bother when I didn’t break this stuff in the first place?” Or, “I didn’t budget for this, so I don’t own this.” In such situations, you must be a good custodian of the org. While you are not expected to go fix all the test classes, at a minimum, you must note which test classes are failing, which lines are failing and what validations are causing the failures, and on which object. Then turn off validation rules, required fields, etc. in production, and then go about your deployment. Once you have successfully deployed, revert everything to the way it was and give all the details to those who will fix them.

The idea is that you catch these issues early and report them before it becomes a problem.

Hope this helps and please leave comments if you have any other suggestions.