Text fields are used to capture free-flowing text. They are used to capture alphanumeric data. The five types of text fields are used to capture different lengths of data:

There are four types of basic text fields, which are as follows:

Picklist is a type of predefined text field. It can be used to prevent spelling mistakes and grammatical errors while entering the data. Picklist is rendered as a drop-down select list on the UI, but it is stored as text in the database. It can store predetermined values, such as City names, State names, and Status:

Picklist (Multi-select) is a special type of picklist that can allow the users to select multiple values at the same time.

Let's take a look at the other general data fields:

Checkbox: This field stores values as true or false. On the page layout or Visualforce, the field is rendered as a checked box for true and an unchecked box for false.

Date: This field captures the date based on a data picker. The Salesforce platform stores the date/time values in the GMT time zone, but the values that are displayed are based on the Locale & Time Zone preferences in My Settings:

Date/Time: This is similar to the date but also captures the time along with the date.

Email: This captures and validates the e-mail values.

Number: This field is used to capture numeric values. We can specify the number of digits before and after the decimal point.

Percent: This field captures the percent data. The values are stored as decimals, such as 0=0%, 0.5=50%, 1=100%, and so on.

Phone: When we enter the phone number through the Salesforce UI, it is auto-formatted as Phone. If we use a third-party softphone with Salesforce, the phone number fields are auto click-to-dial-enabled.

URL: This captures the URL and makes it a clickable link.

Geolocation is a compound field that allows us to identify the location using the latitude and longitude. The geolocation field comprises three separate fields: latitude, longitude, and a field used for internal purposes. The Geolocation field comes bundled with special formulas, such as DISTANCE that calculates the distance between two geolocation fields:

The geolocation field is broken down into separate latitude and longitude components demarked by __s; for example, if the field is called Location, then the latitude is stored as myObject__c.Location__latitude__s and Longitude is stored as myObject__c.Location__Longitude__s.

The Currency field captures the currency values, such as Price and Amount. If your organization has multi-currency enabled, another field called CurrencyIsoCode is visible that allows you to select the type of currency. When multi-currency is enabled, the currency field converts the value into corporate currency and displays it on the field:

We can specify the exchange rate in the setup. We can also specify historic exchange rates for existing values.

Currency fields are easy to export into Excel as they are directly compatible with the Excel currency format.

Let's take a look at the encrypted fields:

If the Salesforce org is storing some sensitive information, such as credit card numbers, social security numbers, bank account numbers, and so on, we can use the encrypted field access to the Salesforce org.

The encrypted fields mask the value of the information with an *. For example, ****-****-****-1234 for a credit card field, as shown in the following screenshot:

We can choose the mask type of the encrypted field, as shown in the following screenshot:

Encrypted fields are used to mask the value of the field from users. The only way to see the encrypted fields is by enabling the View Encrypted Data permission on the profile.

Encrypted fields cannot have default values and cannot be unique or external IDs.

The encrypted field can be edited irrespective of the View Encrypted Data permission. To prevent people from editing them, we need to use the field level security, validation rules, or mark them as read only on the page layout.

Encrypted fields are encrypted with 128-bit keys and use the AES (Advanced Encryption Standard) algorithm. They are 175 characters in length, unlike the normal text field, which is 255 characters.

Due to encryption, there are some limitations on the use of encrypted fields:

Since Summer 2015, Salesforce has offered another level of encryption known as the platform encryption. When we enable the platform encryption, a few standard fields and some custom fields can be encrypted.

The following fields can be encrypted using the platform encryption:

Only users with View Encrypted Field can see the data. For more information on the platform encryption, go to https://help.salesforce.com/HTViewHelpDoc?id=security_pe_overview.htm.

The members of the general library are allowed to borrow the media items for only 15 days. They want to reduce the typing work for the entry clerk and wish to auto-calculate the return date of the book.

The return date will be calculated on the CustomerMedia object that will record the transaction when the book is issued. To create the Return Date formula:

Every time a new record is created with the Issue Date, the Return Date field will automatically calculate and store the return date for it.

A general library wishes to calculate the Penalty Amount for a media resource when it is checked out late. Write a formula field that can calculate the amount for the Customer–Media object.

The formula field is a read-only type of field that is auto-calculated. We define the formula on the basis of other fields and static values and the formulae are auto-calculated globally on the page.

Let's create a formula field to calculate the penalty. Select the Formula field in the list of fields. It will open the Formula creation wizard:

We have already discussed that Force.com is an object-oriented relational database management system. The backbone of the entire system based on Force.com is relationships.

Relationship fields determine how an object is related to another. For example, a library user will have a library card that can issue many books; an Account can have many opportunities. We can create these relationships using the relationship fields.

There are two main types of relationship fields, as shown in the following screenshot:

Let's take a look at each one of them.

Lookup relationship

The lookup relationship is the most basic form of a relationship. The lookup relationship is a foreign key on another object. While creating a lookup relationship, we can determine the behavior of the related record if the primary record is deleted.

If the primary record is deleted, then we need to choose from the following options:

• Clear the value of this field: This option allows us to loosely couple the two records. Deletion of the primary record has no effect on the secondary.
• Don't allow the deletion of the lookup record that's part of a lookup relationship: We can restrict the deletion of a primary record using this option.
• Delete this record also: This allows the cascading deletion of the secondary record.

The Lookup relationship can be visualized in the following figure:

For example, a card of a member can have multiple penalties (fines) on it. The penalties on the card are shown at the bottom of the card in a list.

Lookup relationships have the following properties:

• The two object records have no relationship dependencies on each other
• The lookup field value is optional
• Updating and deleting the child record has no effect on the parent
• Both objects have their own owners and sharing rules
• A record can have 40 lookup fields with 40 different objects

Master-Detail relationship

The following figure illustrates the Master-Detail relationship:

Master-Detail relationships are more tightly coupled relationships. One object is the Master or Primary object and the other is the Detail or Secondary object. The primary object controls the look and style of the tab as well as the security of both the objects. When the primary record is deleted, the secondary record is deleted as well.

For example, the relationship between the customer and the card in the library management will be Master-Detail where the customer is the master and the card is the child in the relationship.

Master-Detail relationships have the following properties:

• The ownership of the child record is given to the master object's owner. The child record does not have a separate owner.
• The detail record inherits the sharing and security settings as well as the look and feel of the master.
• A master record is always required to store the child record.
• If the master record is deleted, the child record is also deleted.
• We can define master-detail relationships between custom objects or between a custom object and a standard object. However, the custom object cannot be on the master side of a relationship with a standard object. In addition to this, we cannot create a master-detail relationship in which the User or Lead objects are the masters.
• An object can have a maximum of two master objects. In cases of multiple objects, both the masters are required. If one master is deleted, the child record gets deleted immediately.
• By default, records can't be reparented in master-detail relationships. However, we can allow child records on custom objects to be reparented to different parent records by selecting the Allow re-parenting option in the master-detail relationship definition.

Note

We cannot create a Master-Detail relationship in an object that contains records in detailed objects. If there are records present in the detailed object, the trick is to create a lookup relationship first. Populate the lookup fields on the existing records and then change them to master-detail.

A general library wishes to keep track of all the media items issued to the customer. They want the total number of items issued in a single field called Media Issued against the member record.

The media items that are issued against the customer are stored in the CustomerMedia object; we will store their count in the Customer object:

This covers the basic formulae and the logic that helps us simplify our work.

In the following section, we will discuss how to automate business processes using workflows and approval processes.

Create a Customer object to collect information about the customer. Create a many-to-many relationship between the customer and media. This object will be used for checkout and checkin of the media item.

The label used to display the field on the page.

This is the number of characters that can be captured in the field.

This gives the general description for audit purposes.

This is the text that will be displayed to the user when they hover over the help icon.

A universally Required field is a custom field whose value is always required whenever a record is saved in Salesforce, the Force.com API, Connect Offline, Connect for Lotus Notes, Connect for Outlook, Salesforce for Outlook, the Self-Service portal, or processes such as Web-to-Lead and Web-to-Case.

To create a universally required custom field, check Always require a value in this field in order to save a record option.

The following fields can be made universally required:

The custom field can be made unique and case-sensitive using this option. Unique fields will automatically get the duplicate check attach while inserting values in them.

To set a field as unique, select the Set this field as the unique record identifier from an external system checkbox, as shown in the previous screenshot.

The general library collects different information about books and videos. Create different fields (as required) to catalog the information.

To create a field on the object, perform the following steps:

A dependent picklist is a picklist whose values are filtered by another controlling picklist. The values in a dependent picklist are changed according to the values selected in the controlling picklist. Standard picklists are always controlling fields. Custom picklists can be dependent as well as controlling.

Exercise – creating a dependent picklist

The general library wishes to create categories and subcategories of books that are available. They first classify the books according to the fiction and nonfiction categories. Fiction books are further classified as children's fiction, fantasy, thriller, and comedy. Nonfiction books are then classified as self-help, management, spiritual, biographies, and inspirational.

We will create the picklist on the Media__c object that we created in our previous exercise.

To create a dependent picklist, we first need to create two normal picklists. First, create a general picklist of the fiction and nonfiction categories, as shown in the following screenshot:

We create another picklist that has all the combined values of fiction and nonfiction, as shown in the following screenshot:

The steps to create a dependent picklist are as follows:

1. Navigate to Setup | Create | Objects, and click on the Media object name.
2. Go to Custom Fields and Relationships | Field Dependencies | New.
3. Most of the chapters in this book are based on custom objects. To customize standard objects, go to Customize | Object Name instead of Create.
4. In the Controlling Field drop-down menu, select Categories, and in the Dependent Field, select Sub Categories.
5. Click on Continue:
   
6. The preceding screenshot shows the interface for creating the dependent picklist. On the X-axis, we have the Controlling Field values and on the Y-axis the values of the Dependent Field are spread.
7. To select the values, press the Ctrl key and select the dependent values by selecting the corresponding controlling value:
   • Fiction: Children Fiction, Fantasy, Thriller, and Comedy
   • Nonfiction: Self-help, Management, Spiritual, Biographies, and Inspirational
8. Click on Include values.
9. Save the record.

Note

If you directly click on Save, the values selected are not saved, so make sure that you click on Include values before Save.

Alternately, you can click on Preview to check whether the values you selected have been assigned. This is a good step if you have more values in the controlling picklist.

On the page layout, you will see that the Sub Categories checkbox is disabled until you select the categories.

Our general library wishes to reinforce the rule on the number of books a user can check out. Every user will have a limited number of books they can issue, depending on their membership type. We will store Total_media_allowed__c in a Number field. Total_Media_Issued__c is a roll-up summary field that stores the number of Media issued to the customer.

To create a validation rule, perform the following steps: