How can we disable triggers, Validation Rules and workflow rules in salesforce org.

This becomes really needed and important when we are doing data migration(data imports) in salesforce.

The way I handled this is create a custom label and include it in workflow and validation rule logic.

example - Custom label 'Disable workflow' = True then do not fire workflows. if its False then fire workflow

But wanted to understand if there is any more efficient way to handle these scenarios.

6 Answers 6


Custom settings are available from both Workflows and Triggers. If you create a "Hierarchy" custom setting object with a checkbox you can reference that checkbox to enable/disable the validation or code. The hierarchy design would allow you to set system wide defaults and then override individual users as needed. Its been pretty effective in a number of occasions.

  • 1
    I think this is the best approach(to create Hierarchy Custom setting) I can think of because of following points - 1. It give flexbilty to have options for specific users. 2. I can create 2 checkbox of custom setting as - Disable Validation Rule, Disable Workflow Rule, Disable Trigger Commented Sep 5, 2012 at 21:22
  • This works great if you are starting from scratch with no pre-existing automations in place, or you are willing to go in and add the custom settings (or custom metadata now) check to each workflow and trigger (which would require writing test code and re-deploying to production). However, a quicker and just as maintainable solution is to use the Salesforce Toolbelt Switch tool referenced in my Answer below. Commented Feb 20, 2017 at 18:16

Till date there is no out of the box functionality available in Salesforce to handle enable and disable Workflow, Trigger and/or Validation in single step.

What we have done is, as you have already explained for Workflow and Validation, use Custom Labels.

For Triggers, we have created custom settings which have two fields - "Logic Name" and "isEnabled".

We follow one Trigger in one Object design, so it is possible that a single trigger is used to execute multiple operations.

In Triggers, before executing any code block, we check if the Logic for that functionality is enabled or not in custom settings. So, from custom setting only, we control the execution of Trigger.

  • 1
    It's not out-of-the-box, but the Salesforce Toolbelt Switch tool (free and open-source) can handle this now, FYI. I reference it in my answer below. Commented Feb 20, 2017 at 18:17

The best way I've seen to handle this is, indeed, to pre-build your validation rules and other logic with some in-built switch. Custom labels are probably the best suited to this if you want to universally turn on/off validation; custom settings would be a perfect fit (since they can be global or user-scoped) but you can't conveniently access them in a number of places. I've seen various other approaches like user role or user name, but those are more brittle.

The problem of course is that you need to either build your org from the ground up with this in mind, or retrofit this logic in hundreds of places. But it's such a common need you'll just get in the habit of putting it everywhere.

If your logic warrants it, I recommend building in more than an on-off switch: build in a number of "switch off" levels so you can gracefully step down to the level of logic you need when data loading. It will cost you almost no more up-front but you'll be thankful. If using custom settings you'll want something compatible with CONTAINS checks. e.g. "123456789" = all checks are on. But removing "9" causes something like all email and chatter notifications to be disabled, "8" disables something like "soft" validation rules, and all of those have checks like

if (Label.myLabel.contains('9')) { // do my stuff

IF(CONTAINS($Label.myLabel, "8"), [fire my semi-optional user-facing validation rule], [auto-pass my rule])

The disadvantage with custom labels of course is that they will have system-wide effects for all users, which won't work for many customers. In those cases, you are probably better off using a single named user or role or profile in these rules (either dedicated API account, or a sys admin user/role/profile) and doing the same type of check against something like username or role AND then using the contents of something like user alias if you want granular on/off control.

  • This works if you are starting from scratch with no pre-existing automations in place, or you are willing to go in and add the custom labels check to each workflow and trigger (which would require writing test code and re-deploying to production). However, FYI there is now a free, open-source tool to do this for validation rules, workflows, processes, flows, and triggers. See my answer below Commented Feb 20, 2017 at 18:19

There now exists a free tool in the Salesforce ecosystem that perfectly meets this need: the Switch utility from Ben Edward's generous Salesforce Toolkit library.

Check out the GitHub project here.

If you do not want to take the risk of giving org access to a 3rd party tool, there is always the option of spinning up a free Heroku instance and installing the Switch utility into it; the README for the GitHub repo link above provides high-level instructions for how to perform the install.

  • You got it, @benedwards44. Some of the best free admin/dev tools I've found! Commented Mar 31, 2017 at 4:19

When importing data via the web interface (Setup > Data Management > Import Object Name), there's the tickbox that lets you decide whether these records should trigger workflow rules. Does this do what you're after?

With validation rules, I'll normally just disable the relevant one(s) while importing data, making sure I re-activate it afterwards.

In regards to triggers, it's not something I've used recently, so hopefully someone else will be able to help.

A side effect of turning off a workflow rule may result in legitimate records (especially time based workflow rules) not being triggered. It's just something to keep in mind.


If you can deploy to the Org, you could use one of the SalesForce APIs to enable/disable the triggers. I've experimented with this in our DX project, and created a plugin for the SFDX CLI. I've posted it in this gist.

For our use case it did not do exactly what we wanted, but perhaps someone else can benefit from it. In a DX project, this mechanism will result in changes in the scratch org (changed timestamps), which have to be pulled into source control, which is an undesirable step. We've opted for the mechanism of first tweaking the source on disk, then pushing that code, doing the import, and then reverting back the changes using Git and pushing the original code again:

$ sed -i "s/<status>Active<\/status>/<status>Inactive<\/status>/" app/main/default/triggers/*-meta.xml
$ sfdx force:source:push -u org
# run import tool
$ git checkout -- app/main/default/triggers/*-meta.xml
$ sfdx force:source:push -u org
  • If the gist is not too long, please edit this post to include the code here.
    – Adrian Larson
    Commented Apr 8, 2019 at 11:07
  • It's long-ish, 95 loc, I'm not sure what the etiquette says on this, what would you recommend? Commented Apr 8, 2019 at 12:56

You must log in to answer this question.

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