Adding default values to your fields improves the usability of your application and can reduce the number of fields needed on the screen, as users can remove fields with acceptable defaults from the layouts.

Default values defined on custom fields apply in the native user interfaces and Visualforce UIs (providing the apex:inputField component is used) and in some cases, through the APIs. You can define a default value based on a formula using either literal values and/or variables such as $User, $Organization, and $Setup.

Let's try this out. Create a Year text field on the Season object as per the following screenshot. Make sure that you select the External ID checkbox as this cannot be changed on the field once the package is uploaded at the end of this chapter. This will become important in the next chapter.

To create a record in the Season object, we need to first create a tab for it. Perform the following steps in the package org to try out this process:

Unfortunately, by default, the Apex code does not apply default values when you construct an SObject in the direct manner via new Season(); however, if you utilize the SObjectType.newSObject method, you can request for defaults to be applied as follows:

Season__c season = (Season__c)
     Season__c.SObjectType.newSObject(null, true);
System.assertEquals('2016', season.Year__c);

However unlikely you feel data theft might be, there are some markets and government regulations that require encrypted fields. Salesforce offers two ways to help ensure your application data is stored in their data centers in an encrypted form. There are two options to consider for encrypting field values at rest, that is records physically stored on permanent storage.

Encrypted field values are visible to those who have the View Encrypted Data permission, which is a facility that may not be something your requirements tolerate. This also includes users whom you grant the login access to, such as through subscriber support. Apex, Visualforce Page, Lightning Components and Validation Rule logic you package can see the unencrypted values, so extra care is needed by developers if you want to mask field values. If your only concern is compliance with encryption at rest, this may not be such an issue for you.

The standard lookup UI from Salesforce can be configured to make it easier for users to recognize the correct record to select, filter out those that are not relevant, and if necessary, prevent them from deleting records that are in use elsewhere in your application, all without writing any code.

Perform the following steps in the package org to try out this process:

First, let's ensure that drivers cannot be deleted if they are associated with a Contestant record (meaning they have or are taking part in a race). Edit the Driver field on the Contestant object and enable Don't allow deletion of the lookup record that's part of a lookup relationship. This is similar to expressing a referential integrity rule in other database platforms.

Now if you try to delete Lewis Hamilton, you should receive a message as shown in the following screenshot. This also applies if you attempt to delete via Apex DML or the Salesforce API.

You've just saved yourself some Apex Trigger code and used a platform feature.

Let's take a look at another lookup feature, known as lookup filters. Formula 1 drivers come and go all the time; let's ensure when selecting drivers to be in races via the Driver lookup on the Contestant record, that only the active drivers are shown and are permitted when entered directly.

Perform the following steps in the packaging org to try out the process:

You can have up to five active lookup filters per object. This is not a limit that is set by your package namespace. So, use them sparingly to give your end users room to create their own lookup filters. If you don't have a strong need for filtering, consider implementing it as an Apex Trigger validation.

Test the filter by attempting to create a Contestant child record for the Spa record. First, by using the lookup dialog, you will see the informational message entered previously and will be unable to select Rubens Barrichello, as shown in the following screenshot:

If you attempt to enter an inactive driver's name directly, this is also blocked as shown in the following screenshot:

This validation is also enforced through Apex DML and Salesforce APIs. Unlike Validation Rules, it cannot be disabled by the end user. However, changes related to records, such as making the Driver subsequently inactive, are permitted by the platform. In this case, the next time the Contestant record is edited, the error given in the preceding screenshot will occur.

Finally, you are also able to display additional columns on the lookup dialogs, which help the user identify the correct record based on other fields. The following steps describe how to do this:

Lookups are a hugely powerful declarative feature of the platform; they are not just used to express the application data model relationships, but they actually enforce the integrity of the data as well, thereby making the user's job of entering data much easier.

When it comes to performing calculations on your data, the platform provides a number of options: reports, Analytics API, dashboards, Apex Triggers, Visualforce, and Rollup summaries. The Rollup summary option provides a code-free solution with the ability to apply some condition filtering. Rollup summary fields can then also be referenced and combined with other features such as formula fields and Validation Rules.

The key requirement is that there is a Master-Detail relationship between the detail records being summarized on the field being added to the master records, such as that between Race and Contestant. The following example will total the number of competitors that did not finish a given race (or DNF in Formula 1 terms).

Perform the following steps in the package org to try out this process:

Navigate to the Spa record and note that the Total DNFs shows the value 1. Experiment by changing the status of the DNF field on the Driver records to see the value recalculate.

Rollup summaries provide a real-time calculation once configured. However, when creating or changing rollups, Salesforce states that it can take up to 30 minutes. You can read more about them by searching for About Roll-Up Summary Fields in the documentation and by reviewing the Roll Up Summary Field Technology Overview knowledge base article at http://help.salesforce.com/apex/HTViewSolution?id=000004281.

As you can imagine, calculating Rollup summaries can be quite an intensive job for the Salesforce servers. As such, Salesforce limits the total number of Rollup summaries to 10 per object, though this can be increased to 25 by contacting Salesforce Support with a valid business case. Keep in mind that as a packaged application provider, this limit is not scoped by your namespace, unlike other limits. This means that if you use all 10, your end users will not be able to add their own post-installation. Similarly, if they have created their own post-installation and an upgrade causes the limit to be breached, the install will fail.