Org Behaviour Custom Setting

As a best practice I implement a hierarchy type Custom Setting (OrgBehaviourSettings__c) which enables a highly useful, org-level selective switching-off of dynamic behaviour such as Triggers. The setting usually has independent flags for workflow rules and validation rules also, with the setting fields being referenced in rule entry criteria and formula expressions respectively. Having such a setting in place (and fully respected across the declarative build and Trigger scripts) from the outset can be really useful for diagnostics and data loading. It may be advantageous in some cases to provide a different set of values for an integration user perhaps – do this with caution..

Example object definition

<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
    <customSettingsType>Hierarchy</customSettingsType>
    <customSettingsVisibility>Protected</customSettingsVisibility>
    <description>Org-level behaviour settings - enable switching-off of Apex Triggers etc.</description>
    <enableFeeds>false</enableFeeds>
    <fields>
        <fullName>TriggersEnabled__c</fullName>
        <defaultValue>true</defaultValue>
        <description>When set to True, Apex Triggers (coded to respect the setting) will execute - when set to false Apex Triggers exit immediately.</description>
        <externalId>false</externalId>
        <inlineHelpText>When set to True, Apex Triggers (coded to respect the setting) will execute - when set to false Apex Triggers exit immediately.</inlineHelpText>
        <label>TriggersEnabled</label>
        <type>Checkbox</type>
    </fields>
    <label>OrgBehaviourSettings</label>
</CustomObject>

Example trigger code

trigger OnAccount on Account (after update
//				after delete, 
//				after insert, 
//				after undelete, 
//				before delete, 
//				before insert, 
//				before update
				) {							
  OrgBehaviourSettings__c obs = OrgBehaviourSettings__c.getInstance();
  System.debug(LoggingLevel.ERROR, obs);
  if (!obs.TriggersEnabled__c) return;	
									  
  AccountTriggerHandler handler = new AccountTriggerHandler(Trigger.isExecuting, Trigger.size);

//    if (Trigger.isInsert && Trigger.isBefore){
//        handler.onBeforeInsert(Trigger.new);
//    } else if (Trigger.isInsert && Trigger.isAfter){
//        handler.onAfterInsert(Trigger.new, Trigger.newMap);
//    } else if (Trigger.isUpdate && Trigger.isBefore){        
//        handler.onBeforeUpdate(Trigger.new, Trigger.newMap, Trigger.oldMap);
//    } else if (Trigger.isUpdate && Trigger.isAfter){
    	handler.onAfterUpdate(Trigger.new, Trigger.newMap, Trigger.oldMap);
//    } else if (Trigger.isDelete && Trigger.isBefore){
//        handler.onBeforeDelete(Trigger.old, Trigger.oldMap);
//    } else if (Trigger.isDelete && Trigger.isAfter){        
//        handler.onAfterDelete(Trigger.old, Trigger.oldMap);
//    } else if (Trigger.isUnDelete){
//    	handler.onAfterUndelete(Trigger.new, Trigger.newMap);
//    }
}

Don’t forget to populate the setting in test code (example below creates default org-level values).

OrgBehaviourSettings__c obs = OrgBehaviourSettings__c.getInstance( UserInfo.getOrganizationId() );
obs.TriggersEnabled__c = true;	
insert obs;

Trackbacks

  1. […] have to), by adding a global Validation Rule switch-off flag in a Org Behaviour Custom Setting (see previous post) – this approach is helpful in many areas but for unit test data creation it can isolate test […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: