When you build solutions on the force.com platform you should always try to make them robust but yet flexible. Customisations you build should be created in a way that they are org independent so that you can handle sandboxes and maintenance in a good way. It is not uncommon that you need to build triggers or classes that to a degree will be org dependent – this is the effect of the business requirements but there are ways to drastically limit the impact on the org.
Let’s say you have a record that needs a trigger to execute some business logic. However this business logic should only happen on a certain record type. To do this filtering you can do a few things. One way could be a custom formula field that would be a checkbox on the record that this tigger is executing on. The trigger should only fire if this field is checked. This means that part of the business logic would be put in the formula for the field. To change this record type or while moving to a different sandbox the formula may need to be updated. This would be a change not requiring code and a deployment and all that is related to it.
As a developer I don’t like this solution since it’s spreading the business logic and it’s harder or at least more cumbersome to troubleshoot and maintain. Another way could be to use Custom Settings to store the record type name or id – and use this value in the trigger to do the filtering. This is probably the way I would go since it is clear while looking at the trigger what the logic is. This article will describe a solution that would easy up and make the usage of the custom settings easy and flexible for both the administrators and the developers.
The solution is built around a very general Custom Setting called Settings which has one field of each type and an additional field called type. This type field will be a pointer to let the system know which field to find the value in and if this value is a single value or if it is a list of values. The general structure of the Settings object is shown in the picture below.
The different values you can put into the type field should are Boolean, Currency, Date, Datetime, Email, Numer, Percent, Phone, Text, Textarea or Url. Case is not important. You can also indicate that it is a list of values by simply suffixing the type with .
The standard name field is used to know what the name of the setting is. If you are using a list type of setting you suffix the name with _n where n should be a unique number and determines which order in the list your value will end up as. n must be a integer.
To make it easy for the developer the Settings class is declared static which means that you do not need to instantiate it – you can reach the values of your settings with only one line of code independently if they are a single value or a list of values.
The following settings has been created
// Load the site name from the custom setting string MySiteName = (string) Settings.get(‘MySiteName’); // Load all the links form the custom setting List<string> MyLinks = (List<string>) Settings.getList(‘MyLinks’);
If you like this tool it’s freely available for you to use and you can get hold of it in two ways.
I’ve prepared a package with all the components you need. Install it to you org and you are good to go. This package is unmanaged which means that you can change and do anything you want with the code.
You’ll find the package here!
The code is also available via GitHub here. Feel free to give suggestions and comments on how you would like to have this developed in the future.
The code is GPL.
This blog post is a repost from Martin’s old blog called webaholic.