Additional Database Features

This section introduces a set of features of the Force.com database that are unique to the way the Force.com platform works. Their configuration and behavior build on the definition of objects and fields, extending them to support more complex native user interfaces, calculations performed on groups of records, and the storage of configuration data.

The following features are discussed in this section:

Roll-up summary fields—Roll-up summary fields are like formula fields that operate on a group of records, calculating their sum, minimum, maximum, or a record count.

Dependent fields—Dependent fields enable the standard “cascading picklist” user interface pattern, in which user selection in one picklist filters the available values in a second.

Record types—Record types allow records in a single object to take on multiple personalities in the native user interface. For example, the standard object Account is designed to store information on businesses, but with minor adjustments can support data on individuals as well. This can be accomplished with record types.

Custom settings—Custom settings store and manage user preferences, aspects of an application that can be configured by users rather than hard-coded by developers.

Roll-up summary fields are the mechanism for instructing the database that you’d like summary data to be calculated without custom code. You specify the child object to summarize, the function to apply to the child records, and filter criteria on the child records. The database then takes care of keeping the roll-up summary values up to date as child records are created, modified, and deleted. For example, given an Invoice Header object and Invoice Line Item child object, you could use a roll-up summary field on the Invoice Header to maintain a running count of invoice line items.

Roll-up summary fields are added to objects using the same process as adding other types of custom fields. There are additional options to define the summary calculation, which consists of three parts:

Summarized object—A drop-down list contains the objects you are permitted to summarize. This is restricted to child objects in a Master-Detail relationship with the object you’re creating the roll-up summary field on. Lookup relationships are not supported.

Roll-up type—Select the calculation to be performed on the child records and the field of the child object to perform it on. The fields available in this list depend on the calculation. If your calculation is Sum, the list contains fields of type Number, Currency, and Percent. With Min or Max, you can also summarize Date and Date/Time fields. Note that you cannot roll up other roll-up summary fields or formula fields that contain references to other objects, merge fields, or functions returning dynamic values such as TODAY and NOW.

Filter criteria—By default, all records are included in the summary calculation. Alternatively, you can also specify one or more filter criteria to restrict the records involved in the calculation. Build filter criteria by selecting a field to filter, the operator to apply, and the value. If you add more than one criterion, the effect is additive. All filter criteria must be satisfied for the record to be included in the summary calculation.

After you have specified the summary calculation and saved the new field, Force.com begins calculating the summary values on existing records. This can take up to 30 minutes. An icon is displayed beside the field to indicate that the calculation is running.

You can define at most ten roll-up summary fields per object. Make a point of creating them toward the end of your database design process because they make it more difficult to change your objects. For example, you can’t convert a Master-Detail relationship to a Lookup relationship without first removing the roll-up summary fields.

A dependent field is an ordinary picklist field with an additional attribute to relate it to a controlling field. To visualize the relationship between the fields, modify your object’s page layout so that the controlling field appears above the dependent field. Then perform the following steps to define the relationship between their values:

1. Navigate to the Custom Field Definition Detail page for the dependent field.

2. In the Picklist Options subsection, click the New link next to the label for Controlling Field.

3. Select the controlling field and click the Continue button.

4. Use the grid to specify which values of the controlling field should be included in the dependent field. Picklist values of the controlling field are shown as columns. Values of the dependent field appear as rows. Double-click individual values to include or exclude them or hold down the Shift key while clicking multiple values and click the Include Values and Exclude Values buttons to make changes in bulk.

For example, Salesforce uses this feature in its CRM product. Person Accounts are a record type of the Account object. Accounts ordinarily store information about businesses, but the Person Account record type adapts Account to store information about individuals. Salesforce opted to overload Account with a record type rather than creating an entirely new object.

Before creating a separate object to represent every business entity, ask yourself if the entity is truly new or merely a slight variation of another entity. Where you find slight variations, consider using a single object to do the work of many. The single object contains a superset of the objects’ fields. The record type of each record determines which variation of the business entity is stored. Force.com consults the record type and the user’s profile to display the correct page layout.

Even if you don’t plan to use the native user interface, record types can expand the flexibility of your data model. By using record types, you gain an additional standard field called RecordTypeId. In custom user interfaces, you can use this to drive different functionality. Of course, you can always add your own custom field to accomplish the same thing, but record types force you to make your design explicit at the native Force.com level and provide tight integration with native Force.com security.

Every object has a default record type called Master. It contains the master list of values for all picklist fields in the object. New record types are cloned from the Master record type if no other record types exist, and given a name, label, and description. Normally, record types are in an active state, which makes them available to users who are creating and editing records. Deactivating a record type is required before it can be deleted.

After a record type is saved, it enters an edit mode. Edit mode permits the maintenance of picklist values for the record type. The list of picklist type fields in the object is shown, with Edit links beside each. These Edit links take you to a screen that allows picklist values to be customized. Here, you can select all, or a subset of the picklist values, and provide a custom default value.

This is just one way to manipulate the picklist values of a record type. When adding new picklist values in an object with more than one record type defined, you are asked which record types they apply to. By default, new picklist values are added only to the Master record type, leaving other record types unchanged.

A custom setting is an object definition, much like a standard or custom database object. It consists of a name, a type, and one or more fields. There are two types of custom settings: List and Hierarchy:

List—The List is the simpler form, behaving like a database object except for the fact that records are accessed one at a time, by unique name. For example, you might define a custom setting with fields representing configurable options in your application, and each named record representing a collection of those options, such as Test and Production.

Hierarchy—The Hierarchy type expands upon the List type, adding the ability to relate data to organization, profile, and user. If a value is not provided for a given level, it defaults to the levels above it. With Hierarchy types, you can create applications that manage settings for individual users, but defer to a profile or organization-wide default when necessary without storing and maintaining redundant, overlapping information.

1. Go to the App Setup area and click Develop, Custom Settings. This is where custom settings are defined and their values maintained.

2. Click the New button to define a new custom settings object. Label is the display name for your object, Object Name is the name by which you’ll refer to it in programs. Enter Config Setting as the Label and ConfigSetting as the Object Name. For Setting Type, select List. Visibility controls how this setting behaves when packaged. Leave it as Protected. Use the Description field to explain the purpose of your custom setting to other developers in your organization.

3. Click the Save button. Your custom setting is now created and needs some fields and data. Each custom setting can have up to 300 fields.

4. In the Custom Fields section, click the New button to create a new field. Custom settings fields use a subset of the data types available to custom object fields. They are Checkbox, Currency, Date, Date/Time, Email, Number, Percent, Phone, Text, Text Area, and URL. Select Checkbox for your field and click the Next button. For the field label, enter Debug. The Field Name, used to refer to the field in code, is automatically populated. Click the Next button.

5. Click the Save button to finish your field definition.

You’re ready to store values in your custom settings object. Force.com provides a standard user interface for this purpose. Click the Manage button and then the New button. There is a field for the Name of the setting record, which serves as a human-readable identifier for the record. Following the name are the custom fields you’ve defined on the custom setting. In this case, you have a single check box field named Debug. Enter Default for the name, check the Debug box, and click the Save button.

When you’ve finished creating the custom setting, add a new value to it. You are prompted to set the value of the Debug field as with the List custom setting example. But there is an additional system field called Location. Location determines at which level in the hierarchy the setting applies. There are two options: Profile and User. Try to create two custom setting records, one with Debug checked for the System Administrator profile and the other a user in that profile with Debug unchecked.