After several salesforce.com implementations, I find myself building common components that aid the build effort. Not starting the build phase on the right foot can cost you dearly, especially in an agile setting where focus is on delivering user stories that add business value. It is hard to sometimes justify the time spent on building components that don't directly add business value but because they can greatly improve the flexibility and maintenance of the solution it is definitely a conversation worth having.
In this series we will look at components such as; a framework for triggers, custom settings and a test factory pattern. In this post we will look at custom settings.
Experienced salesforce developer/administrators know the benefit of custom settings and how they can be utilised, generally speaking they can be thought of as system configuration settings. There are two types; hierarchical and list.
Hierarchical Custom Settings
The excerpt below from a blog post provides a concise and clear description. View the full article here.
Defined once and can hold a unique set of values for the Organisation, each Profile or each individual User. Salesforce automatically grabs the lowest level of setting for the running user when a getInstance() call is made, or when accessed in a configuration such as a Validation Rule, Workflow or Formula Field. Note that only Hierarchical settings can be accessed declarative whereas List settings are for Apex/Visualforce only.
List Custom Settings
Again, a great description by Ali Zafar.
List settings are structured similar to records held in a custom object. They allow you to store org-wide static data that is frequently used, and therefore cached for performance. Data in List settings do not vary by user and profile, there is no ownership, field level security or record security, and it is available organisation wide (i.e. public for all). It is best used for data lists, especially reference code lists, and great for when you want to convert code values from one system to another or any other mapping or list.
Framework Settings
I commonly find myself creating hierarchical custom settings to control whether a triggers, validation rules, workflow rules and assignment rules should be run for a particular user/profile. Below is how this might look once you create the org defaults.
This now gives us the flexibility to turn on/off each of these elements either from the declarative tools or from within code. An example of using this in Validation Rules can be seen here.
The flexibility this offers should be clear, but for the sake of completeness I will provide an example. A common and crucial aspect of most projects is data migration and when you are dealing with legacy systems, the validations you implement in salesforce might hamper your ability to load records. Also, when thinking about data migration running triggers/validation/workflows can have an adverse effect on processing times of the data loads. Especially when the volumes are in the magnitude of millions.
Next up we will look at a common trigger framework.