Custom Settings vs. Custom Objects in Salesforce.com

Salesforce.com Custom SettingsCustom Settings arrived on the scene in Winter ‘10 with very little fanfare, and they haven’t generated much excitement since then. In our travels as consultants, we at OpFocus don’t see them used very often, and it’s a shame, as they have some really useful features. In this article, we’ll explain why Custom Settings can be so useful.

Custom Settings vs. Custom Objects

In some ways, Custom Settings look very much like Custom Objects. In fact, if you use a tool like the Data Loader to view a list of objects in your org, you’ll see that Custom Settings are listed together with Custom Objects, without any visible distinction between the two. However, while both Custom Objects and Custom Settings allow you to define Custom Fields, there are some important differences.

  • Limited field types – Custom Settings support only Checkbox, Currency, Date, Date/Time, Email, Number, Percent, Phone, Text, Text Area, and URL field types. Most notably absent are Formula and Picklist, as well as field types that define relationships to other objects, like Lookup and Master/Detail. You can’t create lookups from Custom Objects to Custom Settings either.
  • No validation rules – You can’t define validation rules on Custom Settings.
  • No workflow or triggers – You can’t define workflow rules or triggers on a Custom Setting. Any validation of data, update of related records, or other actions that you might use workflow or a trigger to perform for a Custom Object have to be implemented differently for a Custom Setting.
  • No page layouts or record types – You can’t re-arrange fields on the page layout for Custom Settings. Custom Settings aren’t really intended to be visible to every-day users. If you need them to be, you can create Visualforce pages to allow users to view and manipulate Custom Setting data.

So if Custom Settings are so limited, why use them?

Avoiding Governor Limits

Depending on how your Apex code interacts with Custom Settings, they can have zero impact on certain governor limits. That’s right – you can retrieve all of the values in a Custom Setting with absolutely no impact on the governor’s count of the number of queries you’ve performed or the number of rows you’ve retrieved.  This makes Custom Settings particularly useful for reference data, like lists of Postal Code / State mappings.

There are a few caveats, however. First, you have to query the Custom Setting in a very specific way in order to take advantage of this “no governor limit” feature. Specifically, you have to use the Custom Setting’s GET methods, not SOQL, to query for data. See the Apex Language Reference for more information. Second, other governor limits, like those on heap size and number of script statements, do still apply. Even with these caveats, though, Custom Settings can provide a welcome relief from the limits on queries and rows.

Hierarchical Access to Data

There are two types of Custom Settings: List and Hierarchy. List-type Custom Settings are very similar to Custom Objects, but Hierarchy-type Custom Settings are very different.  Hierarchy Custom Settings allow you to associate specific rows with specific Users or Profiles. For example, you could define a Hierarchy Custom Setting that associates a different commission rate with different sales reps, with separate rows for each sales rep’s User Id. Then you could add a formula field to the Opportunity object, and reference the Custom setting with a formula like:  $Setup.CustomSettingName__c.CustomSettingFieldName__c.  Whenever someone views an Opportunity record, the formula will be evaluated, and Salesforce will find the Custom Setting row for the currently-running User; if none is found, it will find the row for the current User’s Profile (if one has been defined); and if none is found again, it will find an organization-wide default value (if defined).

This ability to define hierarchical data is very powerful, as it allows you to define user-specific customizations. A common use of Hierarchy Custom Settings is to define application-specific defaults on a user-by-user basis. For example, imagine you’ve developed a Visualforce page displays a list of Accounts, allows the user to select one, and then displays the Cases for that Account. You could store each user’s most recently selected Account in a Hierarchy Custom Setting, and then, the next time the user visits the Visualforce page, it could pre-select the Account that the user selected the last time he was on the page.

More on Custom Settings

One more difference between Custom Settings and Custom Objects: Custom Settings are managed through <Your Name> | Setup | Develop, not Create.

If you’ve used Custom Settings, what have you used them for? If you haven’t used them yet, why not?

fast-track your mission critical project

start here

May 8, 2012

MJ Kahn, SVP of Technology at OpFocus

about the author

MJ Kahn

At OpFocus, MJ architects and constructs solutions that would impress the builders of the pyramids. She solves technical puzzles that would frustrate daVinci. She leaps tall buildings (like the new Salesforce tower) in a single bound.

Well ok, maybe she doesn’t. But she does help lead an amazing team of smart, talented, and dedicated consultants who do. MJ’s job at OpFocus is provide technical leadership and guidance to OpFocus clients and team members so that, working together, we can create innovative yet practical solutions to real-world business problems within the Salesforce ecosystem.

Prior to OpFocus, MJ built an extensive background in technology and has held a variety of development, consulting, and management positions at companies like Sybase, Vignette, and Honeywell, among others. In these roles, MJ’s focus was helping companies effectively and intelligently use technology to solve business problems. An Apex and Visualforce consultant since mid-2008, MJ has worked with scores of companies to help them understand and utilize platforms like Force.com to solve business issues and also guide them in developing their own AppExchange product offerings.