Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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.
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.
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.
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
