Recently I was doing some data manipulation work for a customer when I ran into some issues with Triggers firing when the data was being updated. However, in production environments disabling triggers can be tricky. So what I settled on was using a Custom Setting.
Custom Settings are a way for Salesforce.com admins and developers to create configurations that can be applied to various elements of the environment organization wide on a profile or user basis. Pretty cool and useful.
I’ve been using a variation of this for years with Custom Objects. Custom Settings however, are much quicker because they are stored in the Application Cache and they don’t count against SOQL query limits when you retrieve them. They can be used in not just APEX code but also formula fields, validation rules and of course within a Web Service.
There are two types of Custom Settings:
– List
– Hierarchy
Of the two the List custom settings are the easiest. For example, in the past before the State listbox type if you needed to maintain a list of States you used a custom object. Which in turn required a SOQL query to retrieve it. Now you can use the List type to store these types of lists and retrieve them pretty much anywhere you might need them.
Basically setting up the Custom Setting is the same as creating a Custom Object. One big difference is that you will see a button for “Manage” which will allow you to enter the data in a Standard page layout. Once the settings are entered you can query the Custom Setting like a standard Custom Object:
Custom Settings have instance methods you can invoke for easy access. If you wanted a single value (like a State name):
State__c state = State__c.getInstance('Texas');
if you want the list of all values back into a map:
Map mapOfStates = States__c.getAll();
To get the values back as a List :
List listOfStates = States__c.getAll().values();
Hierarchy settings work differently than lists, and for the sake of this article I’d say that I generally find them most useful for settings I want to apply to a profile or user. The interface for Hierarchy settings already includes the navigation that allows it to drill down and return the lowest value in the Hierarchy (based on the current system user).
So back to the trigger setting. Using the List Custom Setting we create one named “TriggerSupport”. With fields for the Name of the Custom Object (text) and TriggerOff (checkbx).
So let’s say we want to turn off a trigger on the Lead object. Go to the Manage Custom Settings and create an entry for Lead and set the Trigger Off setting to True.
Then in your trigger code:
TriggerSupport__c support = TriggerSupport__c.getAll();
Boolean isOff = support.get('Lead').TriggerOff__c;
if(! isOff)
{
... trigger code ...
}
As you study Custom Settings I’m sure you will find many more uses for it within your organization.
[contact-form]