I have seen a number of posts regarding implementing overrides for triggers, workflow and validation rules using custom settings/labels.

In practice / large complex Salesforce deployments are people actually implementing such a thing?

2 Answers 2


There are definitely use cases for it, and it doesn't necessarily hurt the system to have a check in place.

For instance, say you are building a recruiting app. This app was originally built on a different system and contains legacy data. This app has a before insert trigger on the custom object Interview__c which enforces that the custom date/time field Interview_Date__c has to be in the future. Now, in order to get the legacy data into the system properly, you would have to deploy the objects before the trigger, load the data, and then deploy the trigger. Now fast forward this by 6 months after the deployment. A part of the company was never moved onto the new Salesforce recruiting app when it was deployed and continued using the old system. You now have 6 months worth of data that you need to import. The easiest way to do that would be to set a custom setting value and have your trigger reference it. If the custom setting value is false, it skips the validation, otherwise it runs. You can now lock down the system overnight, switch your flag, and simply load the data. There are no code changes involved and it makes the introduction of new legacy data much simpler.

Now, that was only a single simple example, there are a multitude of others but this was the first one that popped into my head. If you would like me to try to think of more I can do that, but my main point is although it seems counterintuitive, adding something to override your triggers/validation rules/workflow isn't always a bad thing and at times can be very useful.

  • Thank you for detail response. Good example makes sense with app developments. I was thinking more about a global salesforce org with multiple business units and thousands of users using it. Jan 31, 2013 at 23:15
  • 1
    I feel like the larger and more complex the org the more these methods are needed. I've encountered many problems with deployments where a sandbox is out of sync with a production org and it can be a real headache if you can't skip validation in test methods and the like.
    – Matt Lacey
    Feb 1, 2013 at 0:33
  • We have actually had to add some rules like this to skip validation as part of setting up mock data for unit tests. Without it, setting up the entire data model would run through so many triggers that we were actually running into DML statement exceptions simply setting up the data. We are talking large scale applications with very complex data structures here, but that is a perfect use case for it. In a normal situation, the user would never run all of those triggers in a single context, not even through the data loader, but it was needed for some tests. Feb 1, 2013 at 14:51

For an enterprise customer I work with, we have added a custom checkbox field on the User object, named "Validation disabled".

Next - for every relevant workflow rule, validation rule, and trigger across our instance, we have included a conditional filter to exclude User.Validation_disabled__c=True - so for instance - for system-to-system usernames we have checked this as True, so that when any updates are made by this user, these transactions will bypass workflows/validations/triggers and not result in errors.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .