Configuration in Salesforce CRM – Salesforce CRM - The Definitive Admin Handbook Third Edition (2015)

Salesforce CRM – The Definitive Admin Handbook Third Edition (2015)

Chapter 3. Configuration in Salesforce CRM

In Chapter 1, Organization Administration and Chapter 2, User Management in Salesforce CRM, we were introduced to the profile feature in Salesforce that is a controlling mechanism. Profiles are used to determine the functions users can perform, which type of data they can access, and what operations they can carry out on that data.

In this chapter, we will describe in detail the Salesforce CRM record storage features and user interfaces that can be customized, such as objects, fields, and page layouts. In addition, we will see an overview of the relationship that exists between the profile and these customizable features that the profile controls.

This chapter looks at the methods to configure and tailor the application to suit the way your company information can be best represented within the Salesforce CRM application.

We will look at mechanisms to store data in Salesforce and also explore the concepts of objects and fields. The features that allow this data to be grouped and arranged within the application are then considered by looking at apps, tabs, page layouts, and record types. Finally, we take a look at some of the features that allow views of data to be presented and customized by looking at related lists and list views in detail.

The relationship between a profile and the features that it controls

The following diagram describes the relationship that exists between a profile and the features that it controls:

The relationship between a profile and the features that it controls

The profile is used to:

· Control access to the type of license specified for the user and any login hours or IP address restrictions that are set. This was covered in detail in Chapter 1, Organization Administration.

· Control access to objects and records using the role and sharing model. If the appropriate object-level permission is not set on the user's profile, then the user will be unable to gain access to the records of that object type in the application. This was introduced in Chapter 2, User Management in Salesforce CRM, and will be covered in detail in Chapter 4, Data Management.

In this chapter, we will look at the configurable elements that are set in conjunction with a profile. These are used to control the structure and the user interface of the Salesforce CRM application.

Objects

Objects are a key element in Salesforce CRM, as they provide a structure for storing data and are incorporated into the interface, allowing users to interact with the data.

Similar in nature to a database table, objects have properties such as:

· Fields, which are similar in concept to a database column

· Records, which are similar in concept to a database row

· Relationships with other objects

· Optional tabs, which are user-interface components that display object data

Standard objects

Salesforce provides standard objects in the application when you sign up; these include Account, Contact, Opportunity, and so on. These are the tables that contain the data records in any standard tab, such as Accounts, Contacts, and Opportunities.

In addition to standard objects, you can create custom objects and custom tabs.

Custom objects

Custom objects are the tables you create to store your data. You can create a custom object to store data specific to your organization. Once you have custom objects and have created records for these objects, you can create reports and dashboards based on the record data in your custom object.

Fields

Fields in Salesforce are similar in concept to a database column; they store the data for the object records. An object record is analogous to a row in a database table.

Standard fields

Standard fields are predefined fields that are included as standard within the Salesforce CRM application. Standard fields cannot be deleted but nonrequired standard fields can be removed from page layouts, whenever necessary.

With standard fields, you can customize visual elements that are associated with the field, such as field labels and field-level help as well as certain data definitions such as picklist values, the formatting of auto-number fields (used as unique identifiers for the records), and the setting of field history tracking. Some aspects, however—such as the field name—cannot be customized and some standard fields (such as Opportunity Probability) do not allow the changing of the field label.

Custom fields

Custom fields are unique to your business needs and can not only be added and amended, but also deleted. Creating custom fields allows you to store the information that is necessary for your organization.

Both standard and custom fields can be customized to include custom help text that helps users understand how to use the field.

Custom fields

Object relationships

Object relationships can be set on both standard and custom objects and are used to define how records in one object relate to records in another object. Accounts, for example, can have a one-to-many relationship with opportunities; these relationships are presented in the application as related lists.

Apps

An app in Salesforce is a container for all the objects, tabs, processes, and services associated with a business function.

There are standard and custom apps that are accessed using the App menu located in the top-right corner of the Salesforce page, as shown in the following screenshot:

Apps

When users select an app from the App menu, their screen changes to present the objects associated with that app. For example, when switching from an app that contains the Campaign tab to one that does not, the Campaign tab no longer appears. This feature is applied to both standard and custom apps.

Standard apps

Salesforce provides standard apps such as Sales, Call Center, and Marketing.

Custom apps

Optionally, a custom app can include a custom logo. Both standard and custom apps consist of a name, a description, and an ordered list of tabs.

Subtab apps

A subtab app is used to specify the tabs that appear on the Chatter profile page. Subtab apps can include both default and custom tabs that you can set. This is described in more detail in the Salesforce Chatter section in Chapter 7, Salesforce CRM Functions.

Tabs

A tab is a user-interface element that, when clicked on, displays the record data on a page specific to that object.

Hiding and showing tabs

To customize your personal tab settings, navigate to Your Name | My Settings | Display & Layout | Customize My Tabs. Now, choose the tabs that will get displayed in each of your apps by moving the tab name between the Available Tabs and Selected Tabssections, and click on Save. The following screenshot shows you the section of tabs for the Sales app:

Hiding and showing tabs

To customize the tab settings of your users, navigate to Setup | Manage Users | Profiles. Now, select a profile and click on Edit. Scroll down to the Tab Settings section of the page, as shown in the following screenshot:

Hiding and showing tabs

Standard tabs

Salesforce provides tabs for each of the standard objects that are provided in the application when you sign up. For example, there are standard tabs for Accounts, Contacts, Opportunities, and so on.

Standard tabs

Note

The visibility of the tab depends on the setting on the Tab Display setting for the app.

Custom tabs

You can create three different types of custom tabs: Custom Object Tabs, Web Tabs, and Visualforce Tabs.

Custom Object Tabs allow you to create, read, update, and delete the data records in your custom objects. Web Tabs display any web URL in a tab within your Salesforce application. Visualforce Tabs display custom user-interface pages created using Visualforce.

Bear the following in mind when creating custom tabs:

· The text displayed on the custom tab is set using the Plural Label of the custom object, which is entered when creating the custom object. If the tab text needs to be changed, this can be done by changing the Plural Label stored on the custom object.

· Salesforce.com recommends that you select the Append tab for users' existing personal customizations checkbox. This benefits your users, as they will automatically be presented with the new tab and can immediately access the corresponding functionality without having to first customize their personal settings themselves.

· It is recommended that you do not show tabs—by setting appropriate permissions—so that the users in your organization cannot see any of your changes until you are ready to make them available.

· You can create up to 25 custom tabs in the Enterprise Edition and as many as you require in the Unlimited and Performance Editions.

To create custom tabs for a custom object, navigate to Setup | Create | Tabs. Now, select the appropriate tab type and/or object from the available selections, as shown in the following screenshot:

Custom tabs

Renaming labels for standard tabs, standard objects, and standard fields

Labels generally reflect the text that is displayed and presented to your users in the user interface and in reports within the Salesforce application.

You can change the display labels of standard tabs, objects, fields, and other related user interface labels so they can reflect your company's terminology and business requirements better. For example, the Accounts tab and object could be changed to Clients; similarly, Opportunities could be changed to Deals and Leads to Prospects. Once changed, the new label is displayed on all user pages.

Note

The Setup pages and Setup menu sections cannot be modified and do not include any renamed labels. Here, the standard tab, object, and field reference continues to use the default, original labels. Also, the standard report names and views continue to use the default labels and are not renamed.

To change standard tab, objects, and field labels, navigate to Setup | Customize | Tabs Names and Labels | Rename Tabs and Labels. Now, select a language, and then click on Edit to modify the tab names and standard field labels:

Renaming labels for standard tabs, standard objects, and standard fields

Click on Edit to select the tab that you wish to rename.

Note

Although the screen indicates that there is a change in the tab's name, this selection will also allow you to change the labels for the object and fields in addition to the tab name. To change field labels, click through to step 2 in the appropriate screenshot. Enter the new field labels.

Here, we are going to rename the Accounts tab to Clients. Enter the Singular and Plural names, and then click on Next.

Renaming labels for standard tabs, standard objects, and standard fields

Note

Only the following standard tabs and objects can be renamed:

Accounts, Activities, Articles, Assets, Campaigns, Cases, Contacts, Contracts, Documents, Events, Ideas, Leads, Libraries, Opportunities, Opportunity Products, Partners, Price Books, Products, Quote Line Items, Quotes, Solutions, andTasks.

Tabs such as Home, Chatter, Forecasts, Reports, and Dashboards cannot be renamed.

Renaming labels for standard tabs, standard objects, and standard fields

Salesforce looks for occurrence of the Account label and displays an autopopulated screen that shows where the Account text would be replaced with Client. This autopopulation of text is carried out for the standard tab, the standard object, and the standard fields. Review the replaced text, amend as required, and then click on Save.

Renaming labels for standard tabs, standard objects, and standard fields

After renaming, the new labels are automatically displayed in the tab, reports, dashboards, and so on.

Note

Some standard fields, such as Created By and Last Modified By, are prevented from being renamed because they are audit fields that are used to track system information.

You will, however, need to carry out the following additional steps to ensure consistent renaming throughout the system, as these might require manual updates:

· Check all list view names as they do not automatically update and will continue to show the original object name until you change them manually.

· Review standard report names and descriptions for any object that you have renamed.

· Check the titles and descriptions of any e-mail templates that contain the original object or field name and update them as required.

· Review any other items that you have customized with the standard object or field name. For example, custom fields, page layouts, and record types might include the original tab or field name text that is no longer relevant.

If you have renamed tabs, objects, or fields, you can also replace the Salesforce online help with a different URL. Your users can view this replaced URL whenever they click on any context-sensitive help link on an end user page or from within their personal setup options.

Creating custom objects

Custom objects are database tables that allow you to store data that's specific to your organization in Salesforce.com. You can use custom objects to extend the Salesforce functionality or build a new application functionality.

Note

You can create up to 200 custom objects in the Enterprise Edition and 2000 in the Unlimited Edition.

Once you have created a custom object, you can create a custom tab, custom-related lists, reports, and dashboards for users to interact with the custom object data.

To create a custom object, navigate to Setup | Create | Objects. Now, click on New Custom Object, or click on Edit to modify an existing custom object. The following screenshot shows you the resulting screen:

Creating custom objects

On the Custom Object Definition Edit page, you can enter the following:

· Label: This is the visible name that is displayed for the object within the Salesforce CRM user interface and is shown on pages, views, and reports, for example.

· Plural Label: This is the plural name specified for the object, which is used within the application in places such as reports and on tabs (if you create a tab for the object).

· Gender (language-dependent): This field appears if your organization-wide default language expects a gender. This is used for organizations where the default language settings are, for example, Spanish, French, Italian, German, among many others. Your personal language-preference setting does not affect whether the field appears or not. For example, if your organization's default language is English but your personal language is French, you will not be prompted for the gender when creating a custom object.

· Starts with a vowel sound: The use of this setting depends on your organization's default language and is a linguistic check that allows you to specify whether your label is to be preceded by an instead of a, for example, resulting in references to the object as an Order instead of a Order.

· Object Name: This is a unique name that is used to refer to the object. Here, the Object Name field must be unique and can only contain underscores and alphanumeric characters. It must also begin with a letter, not contain spaces, not contain two consecutive underscores, and not end with an underscore.

· Description: This is an optional description of the object. A meaningful description will help explain the purpose of your custom objects when you are viewing them in a list.

· Context-Sensitive Help Setting: This defines what information is displayed when your users click on the Help for this Page context-sensitive help link from the custom object record home (overview), edit and detail pages, as well as list views and related lists. The Help & Training link at the top of any page is not affected by this setting; it always opens the Salesforce Help & Training window.

· Record Name: This is the name that is used in areas such as page layouts, search results, key lists, and related lists, as shown next.

· Data Type: This sets the type of field for the record name. Here, the data type can be either text or Auto Number. If the data type is set to be Text, then, when a record is created, users must enter a text value, which does not need to be unique. If the data type is set to Auto Number, it becomes a read-only field whereby new records are automatically assigned a unique number.

Creating custom objects

· Display Format: As with in the preceding example, this option only appears when the Data Type field is set to Auto Number. It allows you to specify the structure and appearance of the Auto Number field. For example, {YYYY}{MM}-{000} is a display format that produces a four-digit year and a two-digit month prefix to a number with leading zeros padded to three digits. Example data output would include 201203-001, 201203-066, 201203-999 and 201203-1234.

It is worth noting that although you can specify the number to be three digits, if the number of records created crosses 999, the record will still be saved but the automatically incremented number becomes 1000, 1001, and so on.

· Starting Number: As described, Auto Number fields in Salesforce CRM are automatically incremented for each new record. Here, you must enter the starting number for the incremental count (which does not have to be set to start from 1).

· Allow Reports: This setting is required if you want to include the record data from the custom object in any report or dashboard analytics.

Note

Such relationships can be either a lookup or a master-detail relationship.

Lookup relationships create a relationship between two records so that you can associate them with each other. A master-detail relationship creates a relationship between records where the master record controls certain behaviors of the detail record, such as record deletion and security.

When the custom object has a master-detail relationship with a standard object or is a lookup object on a standard object, a new report type will appear in the standard report category. The new report type allows the user to create reports that relate the standard object to the custom object, which is done by selecting the standard object for the report type category instead of the custom object.

· Allow Activities: This allows users to include tasks and events related to the custom object records that appear as a related list on the custom object page.

· Track Field History: This enables the tracking of data-field changes on the custom object records, such as who changed the value of a field and when it was changed. Field history tracking also stores the value of the field before and after the edit. This feature is useful for auditing and data-quality measurement and is also available within the reporting tools. You can set field history tracking for a maximum of 20 fields for Enterprise, Unlimited, and Performance Editions.

· Deployment Status: This indicates whether the custom object is now visible and available for use by other users. This is useful as you can easily set the status to In Development until you are happy with users starting work with the new object.

· Add Notes & Attachments: This setting allows your users to record notes and attach files to the custom object records. When this is specified, a related list with the New Note and Attach File buttons automatically appears on the custom object record page where your users can enter notes and attach documents.

Note

The Add Notes & Attachments option is only available when you create a new object.

· Launch the New Custom Tab Wizard: This starts the custom tab wizard after you save the custom object. The New Custom Tab Wizard option is only available when you create a new object.

Object Limits

You can access Object Limits pages when planning how to customize a particular object or to monitor the current usage and limits, such as the number of custom fields or rules applied.

Standard objects

To access the standard Object Limits page, navigate to Setup | Customize. Click on the name of the desired standard object, and then click on Limits, as shown in the following screenshot (for the Account object):

Standard objects

Here, you can see usage details for these: Custom Fields, Rollup Summary Fields, Custom Relationship Fields, Active Workflow Rules, Total Workflow Rules, Approval Processes, Active Lookup Filters, Active Validation Rules, VLOOKUP Functions,Sharing Rules (Both Owner- and Criteria-based), and Sharing Rules (Criteria-based Only).

Custom objects

To view information about the usage of various fields and rules that have been created on a custom object, you can access the Object Limits window displayed on a custom-object-definitions-related list at the bottom of a custom object definition page.

Note

When an item reaches 75 percent or more of the limit allowed for the object, a warning message appears that identifies what can be done to reduce the amount of usage. The object limit percentages display values that are truncated and not rounded up. For example, if your organization reaches 79.55 percent of the limit for an item, the limit percentage displays 79 percent.

Creating custom object relationships

The considerations to be observed when creating object relationships are as follows:

· Create the object relationships as a first step before you start to build the custom fields, page layouts, and any related list

· The Related To entry cannot be modified after you have saved the object relationship

Note

Each custom object can have up to two master-detail relationships and up to 25 total relationships.

· When you're planning to create a master-detail relationship on an object, be aware that it can only be created before the object contains record data

· Clicking on Edit List Layout allows you to choose columns for the key views and lookups

· The Standard Name field is required for all custom object-related lists and also for any page layouts

Creating custom fields

Before you begin to create custom fields, it is worth spending some time to first plan and choose the most appropriate type of field to be created. You can create many different custom field types in Salesforce CRM, including text, number, currency, as well as relationship types that enable lookup, master-detail, and hierarchical relationships.

Adding custom fields can be carried out by navigating to the field area of the appropriate object:

· For standard objects, navigate to Setup | Customize. Now, select the appropriate object from the Customize menu, click on Fields, and then click on New in the Custom Fields & Relationships section of the object page.

· For custom task and event fields, navigate to Setup | Customize | Activities | Activity Custom Fields. Now, click on the New button.

· For custom objects, navigate to Setup | Create | Objects. Now, select one of the custom objects in the list. Next, click on New in the Custom Fields & Relationships dependencies and field history tracking.

Within the field setup pages, you can set field dependencies and field history tracking for the object. Field history tracking captures information for the date and time, the nature of the change, and who made the change. A dependent field is a picklist field for which the valid values depend on the value of another field.

Whenever history tracking is set, a separate history data object is created for the object. This history data comprises the record ID and the history-tracked field names whose value has been changed. Here, both the old and the new record values are recorded. This is covered later in this chapter in the Custom field governance section.

Note

Field dependencies and field history tracking is not available for task and event fields and are described in more detail later in this chapter.

Choose a data type for the field to be created. The following screenshot shows you the first page (step 1) where a full list of data types (described in detail later) are available to choose from:

Creating custom fields

Some data types are only available for certain configurations. For example, the Master-Detail Relationship option is available only for custom objects when the custom object does not already have a master-detail relationship. The Roll-up Summary option is only available for objects defined as master in the master-detail relationship and is used to record an aggregate of the child records using functions such as SUM, MAX, and MIN (these are described in detail later in this chapter).

Note

Field types not listed in custom field types might appear if your organization installed a package from AppExchange that uses these custom field types.

Click on Next and enter a Field Label. Field Name is a mandatory field and must be unique within the Salesforce CRM application. There are also some restrictions on what can be entered and what not. Here, you can only enter alphanumeric characters and underscores. In addition, the text must start with a letter; it cannot include spaces, it cannot contain two consecutive underscores, and the final character must not be an underscore.

Creating custom fields

Tip

Make both the custom field name and label unique in your application

Ensure that the custom field name and label are unique and not the same as any existing standard or custom field for that object. Creating identical values might result in unexpected behavior when you reference that name in a merge field. If a standard field and custom field have matching names or labels, the merge field displays the value of the custom field. If two custom fields have matching names or labels, the merge field might not display the value of the field you expect. For example, if you create a field label called Phone, the field name automatically populates as Phone_c. If you also have a standard field with the Phone label, the merge field might not be able to distinguish between the standard and custom field names. Make the custom field name and label unique by adding a suffix to each, such as Phone_Custom and Phone_Custom_c, respectively.

For relationship fields, choose the object that you want to associate with it.

Creating custom fields

Note

The number of custom fields allowed per object is 500 for both the Enterprise and Unlimited Editions of Salesforce. Relationship fields count toward these custom-field limits.

Enter any field attributes. In this example, a new checkbox field is set as Checked by default:

Creating custom fields

Object relationship fields allow you to create a lookup filter that can be used to further control the associated returned records and lookup dialog results of the field. These are available for the Lookup, Master-detail, and Hierarchical relationship fields. Here, you can select multiple fields and selection criteria to restrict the results. This is presented in an additional step of the field-creation process and is available in the Lookup Filter section, which is available on the Step 3. Enter the label and name for lookup field setup page.

Click on Next to continue and specify the field's access settings for each profile, as shown in the following screenshot:

Creating custom fields

To set the field-level security, enable the following settings:

The Visible checkbox

The Read-Only checkbox

Result

Checked

Not Checked

Users can view and edit the field

Checked

Checked

Users can view but not edit the field

Click on Next and choose the page layouts to which you would want to add the new field, as shown in the following screenshot:

Creating custom fields

The new field is automatically positioned on the page layout as the final field in the first two-column section. However, there is an exception for Text Area (Long) and Text Area (Rich) fields. Due to their double width, these fields are placed as the final field in the first one-column section in the page layout.

Note

For user custom fields, the field is automatically added to the bottom of the user detail page.

For universally required fields, you cannot remove the field from page layouts or make it read-only.

Click on Save to finish or on Save & New to create more custom fields.

For relationship fields, choose whether you want to create a related list that displays information about the associated records or not. You can choose to put the related list on any page layout for that object.

To change the label of the custom-related list as it will appear on the page layouts of the associated object, edit the Related List Label field. This is covered later in this chapter in the Page layouts and Related lists sections.

To add the new related list to page layouts that users have already customized, check the Append-related list to users' existing personal customizations.

Custom field data types

When creating a custom field, the first step is to select the appropriate type for the field. There are many different field types available in Salesforce that allow the storage of records of various data types, such as numbers, dates, and percentages. The upcoming sections describe the data types that are available.

The following screenshot shows the available data types:

Custom field data types

Auto Number

An Auto Number field produces a unique number that is automatically incremented for each saved record. As such, this is a read-only field where the maximum length is 30 characters, of which 20 are reserved for further prefix or suffix text that you can specify.

Checkbox

Checkbox allows your users to set or unset a value to mark the attribute as either true or false.

Note

When using a checkbox field in a report, use True for values that are checked values and False for unchecked values. The import wizards and the weekly export tool use 1 for checked values and 0 for unchecked values.

Currency

Salesforce provides a Currency field to specifically capture a monetary value. Here, the Salesforce CRM application applies currency-related codes that are applied when working with that field record.

Note

Values lose precision after 15 decimal places.

Date

A Date field provides a way for your users to either pick a date from a pop-up calendar or manually key in the date. Your users can also enter the current date by clicking on the date link positioned to the right of the field.

Date/Time

A Date/Time field provides a way for your users to either pick a date from a pop-up calendar or manually key in the date and the time of the day. Your users can also enter the current date and time by clicking on the date and time link positioned to the right of the field. Here, the time of day includes the A.M.-P.M. notation.

Email

An Email field provides us with the capability to store an individual's e-mail address. The Salesforce CRM application provides a very robust method to verify the correct format of e-mail addresses before they are allowed to be saved. If this field is specified for contacts or leads, users can choose the address when clicking on Send an Email.

Note

You cannot use custom e-mail fields for mass e-mails. Mass e-mails can only be sent to an e-mail address in a standard e-mail field.

Formula

A Formula field enables a method to automatically calculate a value that is obtained from other fields or values stored within Salesforce CRM. These referenced fields are known as merge fields. Formula fields are very powerful and flexible mechanisms. However, a formula field cannot be set to reference itself within a formula irrespective of whether the reference is made directly or indirectly. Further information concerning formulas is covered later in this chapter in the Building formulas section. Salesforce uses the round-half up, tie-breaking rule for numbers in formula fields. For example, 12.345 becomes 12.35 and –12.345 becomes −12.34.

Geolocation

The geolocation custom field allows you to identify locations by their latitude and longitude and calculate the distance between locations.

Note

Geolocation is a compound field that counts toward an organization's limits as three custom fields: one for latitude, one for longitude, and one for internal use.

You can then use the geolocation field with the DISTANCE and GEOLOCATION formula functions to calculate the distance between locations. For example, you can calculate the distance between two geolocation fields (such as between the warehouse and an account-shipping address) or between a geolocation field and any fixed latitude-longitude coordinate.

Note

The geolocation field is currently in beta release and has the following limitations:

· History tracking is not available on geolocation fields

· Geolocation fields cannot be used on custom settings

· Geolocation fields cannot be included in reports, dashboards, validation rules, Visual workflow, workflow, or approvals

· Geolocation fields cannot be searched

· Geolocation fields cannot be accessed within the Schema Builder

· DISTANCE and GEOLOCATION formula functions are available only when creating formula fields or using them in Visual Workflow

Lookup Relationship

The Lookup Relationship field creates a relationship between two records so that you can associate them with each other. For example, opportunities have a lookup relationship with cases that enable you to associate a specific case with an opportunity.

A lookup relationship creates a field that allows users to click on a lookup icon and select another record from a pop-up window. On the associated record, you can display a related list to show all of the records that are linked to it, and you can create lookup relationship fields that link to users and custom or standard objects. See the Building relationship fields section later in this chapter for further options.

Master-Detail Relationship

The Master-Detail Relationship field creates a parent-child type relationship between records where the master record controls certain behaviors, such as security and record deletion, of the detail record.

Master-detail relationship fields can only be created on custom objects that relate to a standard object and not the other way round. If the master record is deleted, then all detail records are also deleted. You can create up to two master-detail relationship fields the custom object. See the Building relationship fields section for further options, discussed later in this chapter.

Note

As a best practice, Salesforce.com recommends that you do not exceed 10,000 child records for a master-detail relationship.

Hierarchical Relationship

The Hierarchical Relationship field type forms a hierarchical lookup relationship between relevant objects. For the user hierarchical relationship, users can use a lookup field to associate one user with another. For example, you can create a custom hierarchical relationship field to store each user's direct manager. See the Building relationship fields section for further options.

Note

This type of lookup relationship is available only for the user object.

Number

The Number field (data type) can be used to enter any number, with or without a decimal place (the number of decimal places can be specified), and be saved as a real number with any leading zeros removed.

Percent

With Percent fields in Salesforce CRM, a percentage sign is automatically appended to the entered number.

Note

Field values lose precision after 15 decimal places. If the decimal value is greater than 15 and a percent sign is added to the number, a runtime error occurs.

Phone

The Phone field allows the users in your organization to enter any telephone number. While saving the record, the Salesforce CRM application will attempt to format it into a known phone format.

When your users enter phone numbers in Phone fields, Salesforce keeps the phone number format that has been entered. However, if the Locale field is set to English (United States) or English (Canada), 10-digit phone numbers and 11-digit numbers that start with 1 are automatically formatted as (800) 555-1234 when you save the record. If you do not want this formatting for a 10- or 11-digit number, you can enter a + before the number, for example, +44 117 123 4567.

Note

If you are using Salesforce CRM Call Center, custom phone fields are displayed with the button, allowing the click-to-dial functionality. Consequently, Salesforce.com recommends that you do not use a custom phone field for fax numbers.

Picklist

The Picklist field allows users to choose a value from a set of predefined text values. The maximum length of the text values is 255 characters.

Picklist (Multi-select)

The Picklist (Multi-select) field allows users to choose more than one picklist value from a set of predefined text values. The maximum length of the text values is 255 characters. When saving and viewing, the data is stored as text along with semicolons, which are used to separate the individual picklist values.

Roll-Up Summary

A Roll-Up Summary field (or RUS) is used to automatically display the summarized values of the related records. This can be a record count of related records or a calculation of the sum, minimum, or maximum values of the related records.

Note

The records must be directly related to the selected record and on the detail side of a custom master-detail relationship with the object that contains the roll-up summary field. For example, a custom account field called Total Number of Branches displays the number of branches the custom object records in the branch-related list for Accounts.

Text

The Text field allows users to enter any combination of alphanumeric characters. The maximum length of the text value is 255 characters.

Text (Encrypted)

The Text (Encrypted) field allows users to enter any combination of alphanumeric characters. The text is then stored in an encrypted form. As an example, you can create a credit card number field named Credit Card Number with a mask type of Credit Card Number and a mask character of X. When users enter data in this field, it is encrypted and stored in the database. When users without the View Encrypted Data permission view the field, Salesforce displays the mask (for example, XXXX-XXXX-XXX-1234) instead of the value that was originally entered.

Note

For the encrypted text, you can set a maximum length of up to 175 characters.

Encrypted fields are encrypted with 128-bit master keys and use the Advanced Encryption Standard (AES) algorithm.

Note

Your master encryption key can be archived, deleted, and imported using the Master Encryption Key Management feature, which is made available by sending a request to Salesforce customer support.

Text Area

The Text Area field allows users to enter alphanumeric characters on separate lines. The maximum length of the text value is 255 characters and a warning is displayed when the number is about to be reached (as shown earlier).

Text Area (Long)

The Text Area (Long) field provides for the storage of up to 32,000 characters that are displayed on separate lines—similar to a Text Area field. However, you can specify a lower maximum length of this field type between 256 and 32,000 characters.

Note

Every time you press Enter within a long text area field, a line break and a return character are added to the text. These two characters count toward the 32,000 character limit.

This data type is not available for activities or products on opportunities. Only the first 254 characters in a rich-text area or a long-text area are displayed in a report.

Text Area (Rich)

Using the Text Area (Rich) data type, your users are provided with a text field that has an embedded toolbar. This toolbar allows simple formatting of the text and provides the addition of images and URL web links.

Note

The maximum size for uploaded images is 1 MB and only the GIF, JPEG, and PNG file types are currently supported.

Also, the toolbar allows your users to undo, redo, bold, italicize, underline, strikeout, add a hyperlink, upload or link to an image, and add a numbered or non-numbered list.

The maximum field size is 32,000 characters, which is inclusive of all the formatting and HTML tags, and only the first 254 characters in a rich text area or a long text area will be displayed in a report.

URL

The URL field allows users to enter a web link.

Note

The URL field can store up to 255 characters. However, only the first 50 characters are displayed on the record detail pages.

When the web link is clicked on, the Salesforce CRM application opens a new browser window that shows you the web page.

Tip

When entering a value in currency or numbers fields

Whenever your users enter values into either a currency amount or a number field, they can use the k, m, or b shortcuts to indicate thousands, millions, or billions. For example, when you enter 7k, it is displayed as 7,000.

Dependent picklists

Dependent picklists are picklists (including multiselect picklists) in which the values available in the picklist depend on the value of another field, which is called the controlling field.

Note

Controlling fields can be any picklist or checkbox field within the same record

Controlling fields that are picklists are fields with at least one or fewer than 300 values. These are used to help with efficient, accurate data entry and help to achieve consistent data.

· To define a dependent picklist, navigate to the field's area of the appropriate object.

· For standard objects, this is carried out by navigating to Setup | Customize | (select the appropriate standard object) | Fields. Then, click on Field Dependencies.

· For custom objects, navigate to Setup | Create | Objects | (select the appropriate custom object). Then, click on Field Dependencies.

Now, click on New, choose a controlling field and dependent field, and then click on Continue.

Use the field-dependency matrix to specify the dependent picklist values that are available when a user selects each controlling field value, as shown in the following screenshot:

Dependent picklists

Finally, click on Save.

Note

Please note the following points:

· Checkbox fields can be controlling fields but not dependent fields

· You can set default values for controlling fields but not for dependent picklists

· Multiselect picklists can be dependent picklists but not controlling fields

· Standard picklist fields can be controlling fields but not dependent fields

· Custom picklist fields can be either controlling or dependent fields

· The maximum number of values allowed in a controlling field is 300

Building relationship fields

When building lookup and master-detail relationship fields, there are various options and settings that you can set, which will enforce data integrity. These options and settings are covered in the next section.

Lookup relationship options

When you create a lookup field on an object, you can choose whether the lookup field is required or is optional. If it is set as optional, you can choose one of the following three actions if the lookup record is deleted:

· Clear the value of this field

· Don't allow the deletion of the lookup record that's part of a lookup relationship

· Delete this record as well

The clear the value of this field option

The clear the value of this field is the default option and is a good choice when the field does not have to contain a value from the associated lookup record.

The don't allow deletion of the lookup record that's part of a lookup relationship option

The don't allow deletion of the lookup record that's part of a lookup relationship option prevents the lookup record from being deleted and is a good choice to restrict deletions if you have dependencies, such as workflow rules, based on the lookup relationship.

The delete this record also option

The delete this record also option works similar to the master-detail relationship and deletes the record whenever the lookup record is deleted. However, such a deletion on a lookup relationship is known as cascade-delete and bypasses security and sharing settings. As a result, users can delete records when the lookup record is deleted even if they do not have access to the related records.

Note

The cascade-delete feature is disabled by default and is available only by sending a request to Salesforce support.

This option is a good choice when the lookup field and its associated records are highly coupled and you need to delete related data whenever the lookup data is removed.

Note

This option is only available within custom objects and is not available for standard objects. However, the lookup field object can be either a standard or custom object.

Master-detail relationship options

When you create a Master-detail field on an object, you can choose Allow Reparenting Option.

Allow Reparenting Option

By default, records in master-detail relationships cannot be reparented. However, you can allow child records in a master-detail relationship to be reparented to a different parent by selecting Allow Reparenting Option in the master-detail relationship definition.

Lookup filters

Lookup filters are used to restrict the values and lookup dialog results for the Lookup, Master-detail, and Hierarchical relationship fields.

You can specify the restrictions by configuring filter criteria that compare fields and values based on:

· The current record

· The related object (via the Lookup, Master-detail, or Hierarchical field)

· The current user's record, permissions, and role

· The records directly associated to the related object

As an example, you can:

· Restrict the Contact Name field on an Account record to allow only those contacts that have a custom status of Active, filtering out inactive contacts

· Restrict the Contact Name field on a case record to allow only those contacts that are associated with the Account record specified in the Account Name field in the Case record

· Restrict the Account Name field on an Opportunity record to allow only those users who have an International profile to create or edit Opportunity records for accounts outside the United States

Optionally, you can click on Insert Suggested Criteria to choose from a list of lookup filter criteria that the Salesforce CRM system suggests based on the defined relationships between the objects in your organization.

You can make lookup filters either required or optional.

For fields with required lookup filters, only values that match the lookup filter criteria appear in the lookup dialog. Invalid values manually entered into the field also prevent the record from saving; Salesforce CRM displays an error message, which you can set.

For fields with optional lookup filters, only values that match the lookup filter criteria appear in the lookup dialog initially. However, users can click on the Show all results link in the lookup dialog to remove the filter and view all search result values for the lookup field. Optional lookup filters also allow users to save values that do not match the lookup filter criteria.

Building formulas

Custom formula fields require additional settings as specified by the Salesforce CRM application. These are carried out using the following actions and steps:

1. Create the Formula field.

2. Choose the data type for the field based on the output of the calculation.

3. Enter the number of decimal places for currency, number, or percent data types.

Note

The setting for the number of decimal places is ignored for currency fields in multicurrency organizations. Instead, the decimal places for your currency setting apply. Salesforce uses the round-half up tie-breaking rule for numbers in formula fields. For example, 12.345 becomes 12.35 and −12.345 becomes −12.34.

4. Click on Next to display the formula creation screen.

Basic formula

To create a basic formula that passes specific Salesforce data, select the Simple Formula tab, choose the field type in the Select Field Type drop-down list, and choose one of the fields listed in the Insert Field drop-down list.

To insert an operator, choose the appropriate operator icon from the Insert Operator drop-down list. Here, you can choose between these operators: + Add, - Subtract, * Multiply, / Divide, ^ Exponentiation, (Open Parenthesis, ) Close Parenthesis, & Concatenate, = Equal, <> Not Equal, < Less Than, > Greater Than, <= Less Than or Equal, >= Greater Than or Equal, && And, and || Or.

Advanced formula

The basic formula feature is quite restricted and you will most likely seek to create more complicated formulas that can be performed by selecting the Advanced Formula tab.

Within this tab, click on Insert Field, choose a field, and then click on Insert.

You can now include merge fields along with advanced operators as well as functions, which are prebuilt Salesforce CRM formulas that you can invoke and pass your input values to.

Tip

Function description and example usage

Select a function and click on Help to view a description and examples of formulas using that function.

The following are the steps to create a new custom field:

1. Click on Check Syntax to check your formula for errors.

2. Enter a description of the formula in the Description box.

3. If your formula references any number, currencies, or percent fields, choose an option to handle blank fields. To give any blank fields a zero value, choose Treat blank fields as zeros. To leave these fields blank, choose Treat blank fields as blanks.

4. Click on Next.

5. Set the field-level security to determine whether the field should be visible for specific profiles or not, and click on Next.

6. Choose the page layouts that should display the field. The field is added as the last field in the first two-column section on the page layout. For user custom fields, the field is automatically added to the bottom of the user detail page.

Note

Formula fields are automatically calculated. Therefore, they are not visible on edit pages and are read-only on record detail pages. Formula fields do not update last-modified date fields

7. Click on Save to finish or on Save & New to create more custom fields.

Note

Formula fields have character and byte size limits and cannot contain more than 3,900 characters

Building formulas – best practices

Some best practices and methods to improve the creation and maintenance of formula fields are as follows:

· Formatting with carriage returns and spacing

· Commenting

Formatting with carriage returns and spacing

Take a look at the following formula:

Sales Tax (Percent) =

IF(TEXT(Account.Market__c) = "US", IF(TEXT(Account.State__c) = "California", 0.0925, IF(TEXT(Account.State__c) = "Nevada", 0.081, IF(TEXT(Account.State__c) = "Utah", 0.0835, 0) )) , 0)

To improve the readability of formula fields, you can add spacing and carriage returns. The preceding formula can be made far easier to understand simply by adding spaces and carriage returns, as follows:

Sales Tax (Percent) =

IF( TEXT(Account.Market__c) = "US",

IF(TEXT(Account.State__c) = "California", 0.0925,

IF(TEXT(Account.State__c) = "Nevada", 0.081,

IF(TEXT(Account.State__c) = "Utah", 0.0835, 0) ))

, 0)

Commenting

Salesforce CRM allows you to put comments in your formulas. These are sections of text that are not run as part of the formula and are typically used to make notes about the formula code, especially if it is particularly complicated. Comments must start with a forward slash followed by an asterisk (/*) and must finish with an asterisk followed by a forward slash (*/).

Comments are useful for explaining specific parts of a formula to other system administrators who're viewing the formula definition. Look at the following code block as an example:

Sales Tax (Percent) =

/* value only set for US opportunities */

IF( TEXT(Account.Market__c) = "US",

/* Check for the US State of the Account record and set accordingly */

IF(TEXT(Account.State__c) = "California", 0.0925,

IF(TEXT(Account.State__c) = "Nevada", 0.081,

IF(TEXT(Account.State__c) = "Utah", 0.0835, 0) ))

)

, 0)

Carefully using comments to prevent parts of the formula from being activated allows you to test and verify the syntax as you construct and iron out bugs in the formula. However, if you try to comment out the entire formula as syntax, an error is shown. Also, you will experience a syntax error if you try to place comments within other comments because this is not supported in the Salesforce CRM application:

/* /* comment */ */

Note

Including comments and formatting with carriage returns and spacing adds to the number of characters used and, therefore, counts against the character and byte size limits

Building formula text and compiled character size limits

There is a text character and byte size limit of 3,900 characters and a limit of 5,000 characters for the compiled characters for formulas.

When this limit is reached, you will be unable to save the formula field and will be presented with the following error:

Compiled formula is too big to execute (7,085 characters). Maximum size is 5,000 characters.

It is common to encounter these limits when building complicated formula field calculations, particularly when building formulas that reference other formula fields. While there is no way to increase this limit, there are some methods to help avoid and work around these limitations; they are listed as follows:

· Use the CASE function for branch conditions

· Use algebra

For formulas that use multiple branch conditions to derive the values, as in the preceding example formula, check whether the market is US and the state is California, Nevada, or Utah. You can replace the nested IF statements and use the CASE statement instead.

Nested IF statements often result in larger compiled sizes where the IF function is used multiple times, as shown in our example:

IF(TEXT(Account.State__c) = "California", 0.0925,

IF(TEXT(Account.State__c) = "Nevada", 0.081,

IF(TEXT(Account.State__c) = "Utah", 0.0835, 0) ))

Using the CASE statement can provide better logic and often results in a smaller compiled size for the formula:

IF( TEXT(Account.Market__c) = "US",

CASE(Account.State__c,

"California", 0.0925,

"Nevada", 0.0685,

"Utah", 0.0475, 0) ,

0)

Using algebra

The compiled size of formula fields increases as you increase the number of fields that are referenced. This is compounded when you are referencing fields that are themselves formula fields. A way to reduce the overall size is to use algebra to avoid the need to reference fields wherever possible. The following example shows you how the Item_Price__c and Support_Price__c fields are used multiple times:

Total Price =

(Item_Price__c + (Item_Price__c * Sales_Tax__c)) +

(Support_Price__c + (Support_Price__c * Sales_Tax__c))

To reduce the compiled size, use simple algebra to avoid multiple uses of the Item_Price__c and Support_Price__c fields, as shown in the following example:

Total Price =

(Item_Price__c * (1 + Sales_Tax__c)) +

(Support_Price__c * (1 + Sales_Tax__c))

Formula field size limit workarounds

There might be situations where the logic that is required for a formula is simply too complex for the current size limitations in formula fields. The proven methods to overcome this are to implement a solution using either of the following:

· Workflow field updates

· Apex trigger updates

There are two ways in which workflow field updates can help provide a formula logic workaround. Firstly, larger and more complex formulas can be saved using the formula-building function within the workflow mechanism. Secondly, large formula logic can be decomposed into smaller functions of resulting data. For example, you could create simple formulas that get the data fed from fields that have been updated by multiple workflow field updates.

Workflows are covered in detail later in this book. However, the general approach to implementing a workflow field update to provide a solution to the formula field limit is to do as follows:

· Create a nonformula field on the object, such as a currency or number field, in place of the desired formula field. Administrators often identify this field with a suffix to indicate that it is a workflow field—for example, Total Price (workflow). This field is then set as read-only on page layouts, as the field can be considered a system field (as it should not be available for manual updating).

· Create a workflow rule that will always fire.

· Create a field update with an appropriate formula to update the workflow field—Total Price (workflow) in our preceding example.

Any subsequent formulas can reference the populated field. The disadvantages to this workaround are that creating many workflows can add to the complexity of the application and might eventually introduce performance issues. Also, whenever an object has multiple complex workflows assigned, the order in which the workflows are evaluated cannot always be guaranteed, which if not properly maintained, can lead to subtle data discrepancies.

Custom field governance

Controlling the creation of fields is necessary in order to avoid adding unnecessary new fields in Salesforce. Without appropriate field creation governance, there is a risk of producing an application with a complex data structure that provides a poor user experience.

This issue can often be observed due to the ease of creating new custom fields. However, there are other causes, such as the following:

· Configuring spontaneous responses to end user field creation requests without gathering full requirements

· Lack of specification or understanding of reporting requirements for field usage

· Creation of fields that are too specific for common uses, thus driving the need to create ever more fields

· Lack of knowledge or awareness of existing fields that could be used rather than creating new ones

As the number of unnecessary fields increases, users will find it ever more difficult to enter the correct data into the correct fields. Therefore, the amount of entered data is reduced along with users' satisfaction, because the application requires less effort to work with. It is all too easy for your users to become dissatisfied, and this can lead to less overall usage and hence poor data quality due to lack of user participation.

Addressing the issue

Create new fields with care because, as each new custom field is added, your application structure increases in complexity. As a system administrator, you are responsible for knowing which fields are used, where they appear on Page Layouts, and which fields are required for reporting.

If the benefits and long-term use for a new field cannot be easily understood, it is unlikely to be of much use. One method to help determine its use is to consider where and how the proposed new field would be used. If it is never going to be reported, it might be worth querying its purpose and value. The following considerations can be made when creating new fields.

More generic field names

Try to make your field names more generic so that they can serve multiple purposes. In some situations, different business units share objects but track different information. Although they might have different requirements, they can often share fields. Here, you need to be proactive, forward-thinking, and reach out to the business and propose fields that can be used across multiple business units.

Field history tracking

Often, there are unnecessary date fields that are used to track milestones or data-processing dates. With native field history tracking, these milestones can be tracked and reported without the need to always create new fields.

Field history tracking can be applied on certain custom and standard fields for custom objects and these core standard objects: Accounts, Cases, Contacts, Contracts, Leads, and Opportunities, using the Set History Tracking button as shown in the following screenshot:

Field history tracking

Upon clicking on the Set History Tracking button, a page appears, displaying the activation of fields history tracking and the selection of the fields to be tracked, as shown in the following screenshot:

Field history tracking

Changes to fields that have been set up for field history tracking will see a new entry to the object's history-related list whenever changes are made to records (where that field is modified). All entries include the date, time, details of the change, and the name of the user that made the change.

Note

Not all field types can have their history tracked. Changes to field types greater than 255 characters are tracked as edited; their old and new values are not recorded.

There is a maximum of 20 fields per object that can be set to be tracked.

Note

Field history data does not count against your organization's storage limit; however, at the time of writing, Salesforce.com is planning to move toward a policy of deleting field history data that is older than 18 months. Here, they recommend establishing your own field history retention policy, such as extracting the data from the system.

Milestone objects

Create milestone objects and related lists to avoid hardcoding date fields on a record. For example, avoid creating fields to track dated historical financial information within an object. Here, you might have to create redundant fields for each year. For example, 2011 Budgets, 2012 Budgets, and so on. Instead, create a Financials object with one set of fields and a corresponding date field where you can create a new record each year. This can result in fewer fields and far better display and reporting.

Chatter

Consider the use of Chatter to eliminate unnecessary fields. Often, text-area boxes are used to track conversation flows such as support comments and internal review. These might no longer be necessary after Chatter is established. Chatter is covered later inChapter 7, Salesforce CRM Functions.

Page layouts

Page layouts are used to organize the display of fields, buttons, custom links, inline Visualforce pages, Report Charts, and related lists on an object detail or edit page. They are used to establish unique layouts for different business scenarios.

The displayed fields within a related list are controlled by the page layout; the name of the related list is determined by the lookup/master-detail relationship on the related object.

Page layouts are comprised of sections that contain buttons, fields, related lists, and customer links that can be edited using the enhanced page layout editor, as shown in the following screenshot. Here, we are showing how we can edit the properties of theAccount Site field.

Page layouts

Within the field sections, the user interface can be used to make a field required or read-only, as shown in the following screenshot:

Page layouts

The enhanced page layout editor showing read-only settings, as indicated with the padlock icons, is shown in the following screenshot:

Page layouts

In the corresponding Account Edit page, the required field for Account Site is displayed with a red bar, as shown:

Page layouts

You can combine page layouts and field-level security to create the lowest possible permission setting. For example, a hidden field (field-level permission) will never be displayed regardless of the page layout. Likewise, a field marked as Always requires a value in this field to save a record will always be required on the page layout.

Page layouts allow you to create and organize sections on a page and show or hide fields within sections.

Note

Hidden fields might still be accessible elsewhere in the application. Use field-level security to restrict all possible means of accessing a field.

Creating and modifying a page layout

To create or modify a page layout, navigate to Setup | Customize. Select the appropriate object and click on Page Layouts. In the Page Layouts page, you can either click on the New button or choose the existing page layout to modify and click on Edit, as shown in the following screenshot:

Creating and modifying a page layout

When clicking on the New button, you can optionally choose an existing layout to copy.

Tip

Creating a page layout based on an existing page layout

In the enhanced page layout editor, select an existing page layout from the list of page layouts, and then click on Save As to create a copy of the layout.

In the original page layout editor, select an existing page layout from the list of page layouts, and then click on the Clone button.

Enter a name for the new page layout and finally, click on Save.

You can set different page layouts for profiles and different page layouts for record types.

Record types

Record types are a feature of Salesforce CRM that allow you to provide different sets of object picklists, different page layouts, and custom business processes to specific users based on their profile. Record types can be used in various ways, for example:

· Create record types for opportunities to differentiate your internal sales deals from your field sales deals and show different fields and picklist values

· Create record types for leads to display different page layouts for your telesales leads versus your internal sales prospective functions

Creating a record type

The record type called Master is always set for every object and contains all the picklist and process options. It is not, however, listed under the record types list and it can be assigned a record type for a profile, provided it is only assigned as a record type for that profile.

As each record type is assigned to one page layout type per profile, the numbers of page assignments can easily increase. This means that, if you have two custom record types for an account and five profiles, you will have 15 page assignments (5*2 for each custom record type and five for the Master record type).

Selectable record types are assigned per profile, and field-level security is configured separately for each record type. Consider the following when creating a record type:

· Which record types are associated with the current profile?

· If more than one record type is associated with the current profile, prompt the user for record-type selection

· If only one record type is associated with the current profile, select that record type without prompting (this would be set as the default)

· Based on the record type and profile, assign the appropriate page layout

· Based on the record type, assign the appropriate process and picklist values

By associating different record types with different page layouts, fields, and picklist values, you can formulate a set of object-specific processes. In Salesforce CRM, the following are available:

· The Lead process using the Lead object, which is governed by the Status field (which is configured to be open, closed, and so on)

· The Sales process, which uses the Opportunity object and the Stage field (set to be won, lost, and so on), plus the Amount and Probability fields

· The Support process, which uses the Case object and is controlled by the Case Status field (this might be set to open, closed, and so on)

· The Solutions process, which uses the Solution object and the Status fields (set to be draft, deployed, and so on)

For example, your sales team creates an opportunity that represents a sales deal. Your sales support team then upsells this deal. You can then create two sales processes with two different record types and two different page layouts: Sales and Support.

You would want to create a lookup relationship from opportunity to opportunity and only require or display this relationship for the support team profile.

You would also be able to configure the sharing rules so that they cannot modify each other's opportunities. This is covered in detail in Chapter 4, Data Management.

Related lists

Related lists are displayed on the lower portion of the object detail page to display the related record details. Related lists show you the object records that are associated with that record.

From a related list, you can:

· Click on the object record name to view detailed information

· Click on Edit or Del to edit or delete the object record

· Click on New to create a new object record that is associated with the record you are viewing

To define whether an object can be related to another type of record, you would use either a master-detail or a lookup relationship.

Here, we show you how editing a page layout for the account object enables the arrangement and configuration of any related list:

Related lists

The following screenshot shows you the results of changing the related lists in the page layout editor screen when navigating to the Account detail page:

Related lists

List views

When you click on a tab, the Accounts tab for instance, you will be shown the My Accounts field in that view. This is termed as a list view and can be seen as shown in the following screenshot:

List views

Other list views can be selected from the picklist.

List views

You can modify existing views and define which columns and buttons (including standard and custom buttons) are to be displayed. You can click on New to create new views.

List views

The following points apply to list views:

· Every object in Salesforce CRM that is associated with a tab automatically has at least one list view. If there is no tab set up for the object, then there will be no corresponding list view.

· List views can be modified by assigning filter criteria to control which records are returned for the affected object.

· List views can be set up to be seen and accessed only by you, or you can set them to be accessed by certain roles and groups of individuals.

· List views have a print feature that can be used by you and your users. To print from a list view, click on the printable view button located in the top-right corner of the page, as shown:

List views

Note

Printable list views need to be enabled organization-wide for the print feature to be available. See user interface settings in Chapter 1, Organization Administration.

Force.com Quick Access menu

Whenever you want to view or configure object or app-related setup information, use the Force.com Quick Access menu to navigate directly to the relevant customization option.

The Force.com Quick Access menu is available from the object list view pages and record detail pages and provides shortcuts to the configuration features within Salesforce CRM.

The menu can be accessed by clicking on the arrow located on the right-hand side margin of the screen, as shown in the following screenshot:

Force.com Quick Access menu

You can then use the links to navigate directly to the desired setup page, or you can remove the menu by clicking on Turn off menu (this will remove the option from all list views and record pages), as shown in the following screenshot:

Force.com Quick Access menu

You can restore the menu by navigating to Setup | My Personal Information | Personal Information. Now, click on Edit on the user detail page, select Force.com Quick Access Menu, and then, finally, click on Save.

Summary

In this chapter, we described the ways in which the data structure and user-interface features can be configured within Salesforce CRM.

We looked at how object and records information can be accessed. We also looked at mechanisms for managing the methods that users use to view this information using views and page layouts.

We examined how these record structures and user interfaces are controlled by profiles and the wider picture for the way configuration of these concepts are applied for users.

We discussed some techniques to help govern the way the configuration and creation of fields can be carried out and some common pitfalls to avoid.

In the next chapter, we will look in detail at the mechanisms that control access to data records and the features that provide data management and record sharing.