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

Chapter 4. Data Management

In the previous chapters, we looked at how Salesforce controls access to information using the user profile mechanism. We saw how the appropriate object level permissions, such as create, read, update, and delete, have to be set on the user's profile to allow the user's corresponding permissions to the records of that object type.

In this chapter, we will look at organization-wide sharing defaults, roles, and other sharing settings that complement and extend the assigning of access permissions to users within the Salesforce CRM application.

This chapter also looks in detail at some of the mechanisms to control record updates and features that are available to govern and control the quality of data entered into the application.

Finally, we will look at some of the data utilities that are available to import and export data to and from the system.

The data access security model

There are several flexible options that are available for you to control how records are accessed within your organization.

In the previous chapter, we looked at the broadest way in which you can control data by setting properties for the objects that a user can view, edit, and create through the configuration and assignment of profiles.

We also looked at the creation of fields and field-level security that is set at the profile level and is applied to records at the database level. Returning to the diagram, we will now look at the security model shown in the top-right corner of the following diagram:

To specify and set the individual records that a user can view and edit, we now look at other mechanisms that can be applied, which are setting your Organization-Wide Defaults, defining a role hierarchy, and creating sharing rules.

The following diagram shows how, with the addition of each extra feature shown, access to records is broadened:

Organization-Wide Defaults (OWDs) for sharing

Organization-Wide Defaults (OWDs) sharing settings are used to define the default sharing settings for an organization. For most objects, the sharing settings can be set to Private, Public Read Only, or Public Read/Write.

Organization-wide sharing default settings, often referred to in Salesforce CRM as OWDs, specify the default level of access to records and can be set separately for most of the objects in Salesforce, such as accounts, contacts, and activities.

Note

When setting up OWDs, you can set the access level for internal users using the Default Internal Access settings and set a different default access level for external users using the Default External Access settings.

As shown in the preceding diagram, along with the user's profile the OWD defines the baseline level of access to data records that users do not own. The diagram represents the visibility or data access that is increasing as the other features are incorporated to provide wider sharing settings.

To customize your OWD settings, navigate to Setup | Security Controls | Sharing Settings. Now, click on Edit in the organization-wide defaults area, and then select Default Internal Access for each object you want, as shown in the following screenshot:

OWD access level actions

The OWD access levels allow the following actions to be applied to object records:

Public Full Access (Campaigns only)

Access levels for the Campaign OWDs can be set to Private, Public Read Only, Public Read/Write, or Public Full Access. When Campaign is set to Public Full Access, all users can view, edit, transfer, delete, and report on all Campaign records.

For example, in the scenario where John is the owner of Campaign, all other users in the application can view, edit, transfer, or delete it.

Note

This option is available only for the Campaign object.

Public Read/Write/Transfer (Cases or Leads only)

Access levels for Case or Lead OWDs can be set to Private, Public Read Only, Public Read/Write, or Public Read/Write/Transfer. When Case or Lead are set to Public Read/Write/Transfer, all users can view, edit, transfer, and report on all Case or Leadrecords.

For example, if Lucy is the owner of WidgetX case number 101, all other users can view, edit, transfer ownership, and report on that case. However, only Lucy can delete or change the sharing on case number 101 (see the Manual sharing rules section later in this chapter).

Note

This option is available only for Case or Lead.

Public Read/Write

All users can view, edit, and report on all records.

For example, if Mike is the owner of the Account record Emerald Inc., all other users can view, edit, and report on the Emerald Inc. account. However, only Mike has the ability to delete the Emerald Inc. account record or alter the sharing settings.

Public Read Only

All users can view and report on records, but they cannot edit them. Here, only the record owner and users above that user's role in the role hierarchy can edit the records.

For example, Nicole is the owner of the Account record EuroCorp Inc. and Nicole works in the International Sales department and reports to Julia, who is the VP of International Sales. In this scenario, both Nicole and Julia have full read/write access to EuroCorp Inc.

Now, say, Mike also works in International Sales; however, with the Public Read Only setting, he can view and report on the EuroCorp Inc. account record but cannot edit or delete it.

Private

Only the record owner and users above that role in the hierarchy can view, edit, and report on these records.

For example, if Mike is the owner of an Account record, and he is assigned to the role of International Sales and reports to Julia, who is the VP of International Sales, then Julia can also view, edit, and report on Mike's accounts.

No Access, View Only, or Use (Price Book only)

Access levels for the Price Book OWDs can be set to either No Access, View Only, or Use. Use is the default access level and allows all users to access the Price Book information as well as to use the Price Book configuration for opportunities with products.View Only allows users to access Price Book information but not to use that Price Book detail in opportunities with products. No Access restricts users from accessing information for Price Books and Prices.

Note

This option is available only for Price Books.

Granting access using hierarchies

By default, Salesforce uses hierarchies, such as the role or territory hierarchy, to automatically grant record access to users above the record owner in the hierarchy.

This automatic granting of access to users' data to other users higher up in the Salesforce CRM hierarchy can be disabled for custom objects using the Grant Access Using Hierarchies checkbox. When this checkbox is not selected, only the record owner and users granted access by the OWD gain access to the records. For standard objects, the Grant Access Using Hierarchies checkbox is set by default and cannot be unchecked.

Here, we see the options available for an example custom object where, for the custom object Country, we have set the default access to Public Read/Write and the Grant Access Using Hierarchies setting is checked as shown in the following screenshot:

Controlled by Parent

When Controlled by Parent is set on an object, as a result of the object being the detail side of a master-detail relationship, a user can perform an action (such as view, edit, or delete) on the record based on whether they can perform that same action on the parent record associated with it. For example, if a Contact record is associated with the WidgetX account using Controlled by Parent, then a user can only edit that contact if they can also only edit the WidgetX account record.

Note

Tasks and Events are set to Private by default (via the Activity setting shown in the preceding screenshot). To allow users to update each other's activities (for example, to permit a user to set a task that they do not own to complete), you will need to set the Activity setting to be Controlled by Parent and ensure that the object that is related to the activity is also accessible to that user.

When a custom object is on the detail side of a master-detail relationship with a standard object, its OWD is automatically set to Controlled by Parent and it is not editable, as shown in the following screenshot for the custom object Book:

Although Grant Access Using Hierarchies can be deselected to prevent users who are higher in the role or territory hierarchy from having automatic access, users with the View All and Modify All object and View All Data and Modify All Data profile permissions can still access records they do not own.

OWDs need to be defined separately for any custom objects that are created in the Salesforce CRM application.

For some standard objects, you cannot actually change the OWD setting.

For example, the OWD for the Solution object in Salesforce is preset to Public Read/Write, which cannot be changed.

You can use OWDs to set the default level of record access for the following standard objects where the default organization-wide sharing settings are as follows:

External Organization-Wide Defaults (OWDs) for sharing

Organization-Wide Defaults, often referred to in Salesforce CRM as OWDs, specify the default level of access to records and can be set separately for most of the objects in Salesforce, such as accounts, contacts, and activities.

External OWDs allow you to apply a different default access level for external users, such as Chatter external users, Community users, Customer Portal users and so on.

Using External OWDs allows you to simplify the sharing model for your organization. For example, without External OWDs, if you wanted Public Read Only or Public Read/Write access for internal users but Private for external users, you would have to set the default access to Private and create a sharing rule to share records with all internal users. With separate OWDs, one for internal and one for external users, you can achieve similar behavior by setting the default internal access to Public Read Only or Public Read/Write and the default external access to Private.

Note

External OWDs can be used to set sharing for Accounts (and their associated contracts and assets), Cases, Contacts, Opportunities, Users, and Custom Objects

Having separate OWDs, one for internal and one for external users, also speeds up the performance of reports, list views, and searches.

Note

External users include authenticated website users; chatter external users; community users; customer portal users; guest users; high-volume portal users; partner portal users; and service cloud portal users

To activate External OWD settings, navigate to Setup | Security Controls | Sharing Settings. Now, click on the Enable External Sharing Model button, as shown in the following screenshot.

Effects of modifying the default access type

When you change the default access type, say, from Private to Public Read/Write, the organization record sharing for that object is recalculated and you might be presented with a warning confirmation dialog message, as shown in the following screenshot, notifying that an e-mail will be received when the OWD update finishes.

Granting users additional access

Where the OWD setting for an object is Private or Public Read Only, you can grant users additional access to records with the use of permission sets, role hierarchies, and sharing rules.

Note

Sharing rules and permission sets can only be used to grant additional access and cannot be used to restrict access to records from what was originally specified with the OWD.

Permission sets

Permission sets allow you to further control access to the system for the users in your organization. They can be considered a method to fine-tune the permissions for selected individuals and enable access in a way that's similar to the setting up of profiles.

While an individual user can have only one profile, you can assign multiple permissions and permission sets to users. For example, you can create a permission set called Convert Leads that, say, provides the facility for the conversion and transfer of leads usingApp Permissions and assigns it to a user who has a profile that does not provide Lead Conversion. You can create a permission set called Export Reports that, say, uses System Permissions Export Reports to allow specific users to export data from reports. You can also create a permission set called Access Widget using an Object Settings permission, which is associated with a custom object called Widget that is set in the OWDs as Private. Here, you can assign it to a user who has a profile that does not include the ability to access Widgets through their profile settings.

There is a two-step process to set up permission sets for users, and it includes:

1. Creating the permission set from the Permission Set edit page.

2. Assigning the user to the permission set from the User edit page.

Creating the permission set from the Permission Set edit page

To view and manage your organization's permission set, navigate to Setup | Manage Users | Permission Sets. For a new permission set, click on the New button and complete the permission set information and Select the type of users who will use this permission set sections. Now, edit Object Permissions and Field Permissions and choose the required object.

The following screenshot shows the creation of a permission set that allows users to use the Access the Widgets object (set to Private in the OWD access model).

Assigning the user to the permission set from the User edit page

To view and manage which of your users are assigned to permission sets, navigate to Setup | Manage Users | Users. Now, choose a user by clicking on their username. Click on Permission Set Assignments, and then click on Edit Assignment to view and choose from the list of available permissions. The following screenshot shows you the resulting section:

Note

You can create up to 1,000 permission sets for your organization.

You can group multiple permissions into a permission set to create specific profile-like permissions without actually having to create or clone complete profiles that are often unnecessary and time consuming.

Role hierarchy

Once the OWDs have been established, you can use a role hierarchy to ensure that managers can view and edit the same records as their line reports (or subordinates). Users at any given role level are always able to view, edit, and report on all data owned by or shared with users below them in the hierarchy unless the OWD settings specify that you can ignore the hierarchies.

To view and manage your organization's role hierarchy, navigate to Setup | Manage Users | Roles, as shown in the following screenshot:

Here, you can choose to view the hierarchy in one of the following options.

The show in tree view option

The Show in tree view option displays a visual representation of the parent-child relationships between your roles. Click on Expand All to see all roles or on Collapse All to see only top-level roles. To expand or collapse an individual role node, you can click on the plus [+] or minus [-] icon, as shown in the preceding screenshot.

The show in sorted list view option

The Show in sorted list view option displays the roles as a list that you can sort alphabetically by role name, parent role (Reports to), or Report Display Name. If your organization has a large number of roles, this view provides a far easier way to navigate the hierarchy, as shown in the following screenshot:

To show a filtered list of roles, select a predefined list from the View drop-down list, or click on Create New View to define your own custom view of roles. To edit or delete any view you have created, select it from the View drop-down list and click on the Edit link. Once you're on the Edit View page, you can click on the Delete button to delete the list view.

The show in list view option

The Show in list view option displays the roles as an indented list of roles and their child nodes, grouped alphabetically by the name of the top-level role as follows:

Note

The columns are not sortable.

To create a role, click on New Role or Add Role, depending on whether your view of roles is using the list view or tree view, and enter the role fields as required.

Note

You can create up to 500 roles for your organization.

To edit a role, click on Edit next to a role name, and then update the role fields as required. You can delete a role by clicking on Del next to the role name.

To assign other users to a role, click on Assign next to the role name and to view detailed information about a role, click on the role name.

Note

If your organization uses territory management, forecasts are based on the territory hierarchy instead of the role hierarchy.

Role hierarchies do not need to represent your company's organization chart; instead, each role in the hierarchy should be considered as a level of data access that your users or groups in Salesforce require.

Depending on your sharing settings, roles can control the level of visibility that users have into your organization's data. Users at a particular role level can view, edit, and report on all data that is owned by, or has been shared with, users below them in the hierarchy. This is assuming your organization's sharing mechanism for that object type does not specify otherwise.

Specifically, in the OWDs related list, if the Grant Access Using Hierarchies option is disabled for, say, a custom object, only then can the record owner and users who are granted access by the OWDs access that custom object's records.

Although it is possible to create a user record without a role, users would need to be assigned to a role so that their records will appear in opportunity reports, forecast roll-ups, and any other displays based on roles.

Note

When an account owner is not assigned a role, the sharing access for related contacts is Read/Write, provided the OWD for contacts is not Controlled by Parent. Sharing access on related opportunities and cases is No Access.

Users who are to have access to all records in Salesforce CRM should be set at the top-most position of the role hierarchy.

When you change a user's role, any relevant sharing rules are reevaluated to add or remove access to records as required.

Note

It is not necessary to create individual roles for each and every job title within your company. Instead, aim to define a hierarchy of roles that will help control the access of information entered by users in lower-level roles.

To view detailed information about a role, navigate to Setup | Manage Users | Roles. Clicking on the role name will present the role details page, as shown in the following screenshot:

To view the Role Detail page for a parent or sibling role, click on the role name in the hierarchy or siblings list.

To edit the role details, click on Edit.

To remove the role from the hierarchy, click on Delete.

Within the Users, in Role related list, you have the following options:

· Assign a user to the role by clicking on Assign Users to Role

· Add a user to your organization by clicking on New User

· Modify the user information by clicking on Edit next to a user's name

· View a user's details by clicking on the user's Full Name, Alias, or Username

Note

When you edit roles, sharing rules are usually automatically reevaluated to add or remove access to records as required. If these changes result in too many records changing at once, a message appears, warning that the sharing rules will not be automatically reevaluated and that you have to manually recalculate them (as shown further). Sharing rules should be used when a user or group of users needs access to records not already granted to it with either the role hierarchy setup or the OWD settings.

When you modify users in a role, any sharing rules are also reevaluated to add or remove access as required.

Organization-Wide Defaults and sharing rules

A user's level of access to records will never be more restrictive with the use of sharing rules than the options chosen in the OWDs. The OWDs are a minimum level of access for all users.

Sharing rules

With sharing rules, you are, in effect, setting automatic extensions to your organization-wide sharing settings for particular sets of users. As shown in the following screenshot, this can be considered to open up visibility and access to records for these users:

Sharing rules apply to:

· All new and existing records owned by the specified role or group members

· Both active and inactive users

Sharing rules extend the access specified by OWDs and the role hierarchy.

Note

Sharing rules can never be stricter than your OWD settings and allow wider data access for the included users or groups of users. To define sharing rules, navigate to Setup | Security Controls | Sharing Settings. Now, scroll down to the lower part of the page to reveal the Sharing Rules sections.

The following screenshot shows you the Sharing Rules page where there are sections to set the sharing rules for the various standard objects within the application, such as Lead, Account, and Contact, as well as any custom objects in your organization:

Within the Sharing Rules setup section, the following object sharing rules can be applied.

Account sharing rules

Account sharing rules are based on the account owner or other criteria, including account record types or field values, and set the default sharing access for accounts and their associated Contract, Asset, Opportunity, Case, and (optionally) Contact records.

Account territory sharing rules

Account territory sharing rules are based on territory assignment and set the default sharing access for accounts and their associated Case, Contact, Contract, and Opportunity records.

Campaign sharing rules

Campaign sharing rules are based on Campaign owner and set the default sharing access for the individual Campaign records.

Case sharing rules

Case sharing rules are based on the Case owner or other criteria, including case record types or field values, and set the default sharing access for the individual case and associated account records.

Contact sharing rules

Contact sharing rules are based on the Contact owner or other criteria, including contact record types or field values, and set the default sharing access for the individual contacts and associated account records.

Lead sharing rules

Lead sharing rules are based on the Lead owner and set the default sharing access for the individual lead records.

Opportunity sharing rules

Opportunity sharing rules are based on the Opportunity owner or other criteria, including opportunity record types or field values, and set the default sharing access for the individual opportunity and their associated account records.

User sharing rules

User sharing rules are based on group membership (described later in this chapter) or other criteria and set the default sharing access for the individual user records.

Custom object sharing rules

Custom object sharing rules are based on the custom object record owner or other criteria, including custom object record types or field values, and set default sharing access for individual custom object records.

Groups

Groups allow you to simplify the setting up of OWD sharing access via a sharing rule for sets of users or for individual users to selectively share their records with other users.

Public groups

Public groups are sets of users that only administrators are permitted to create and edit. However, when created, public groups can be used by everyone in the organization.

Public groups can contain individual users, users in a particular role or territory, users in a specified role along with all the users below that role in the role hierarchy, or other public groups.

Personal groups

Personal groups are sets of users that everyone can create and edit for their personal use.

Personal groups can contain individual users, public groups, the users in a particular role or territory, or the users in a particular role along with all the users below that role or in the hierarchy.

Effects of adding or modifying sharing rules

When you add a new sharing rule, the access levels for the sharing rule are calculated, and you are provided with a warning confirmation dialog message, as shown in the following screenshot, indicating that this operation could take a significant time:

Changing or deleting sharing rules as well as the transferring of records between users causes reevaluation of appropriate record access for the impacted users.

Note

If these changes affect too many records at once, a message appears, warning you that the sharing rules will not be automatically reevaluated and you must manually recalculate them.

The following list outlines what changes can be done to Sharing Rules and the consequence of applying these changes:

· When you change the access levels for a sharing rule, all existing records are automatically updated to reflect the new access levels

· When you delete a sharing rule, the sharing access created by that rule is automatically removed

· When you transfer records from one user to another, the sharing rules are reevaluated to add or remove access to the transferred records as required

· When you modify which users are in a group or role, any sharing rules are reevaluated to add or remove access to these users as required

· Users who are higher in the role hierarchy are automatically granted the same access that users below them in the hierarchy have from a sharing rule

Note

When you edit groups, roles, and territories, sharing rules are usually automatically reevaluated to add or remove access as required.

Manually recalculating sharing rules can be performed at any time.

To manually recalculate sharing rules, navigate to Setup | Security Controls | Sharing Settings. Now, scroll down to the lower part of the page to reveal the Sharing Rules sections and in the Sharing Rules related list for the object you want, click onRecalculate, as shown in the following screenshot:

Criteria-based sharing rules

Criteria-based sharing rules are used to control which users have access to records based on specified field values on the records. For example, the account object has a custom picklist field named Market. You can create a criteria-based sharing rule that shares all accounts in which the Market field is set to US with, say, a North American Sales team in your organization, as shown in the following screenshot:

Although criteria-based sharing rules are based on values in the records and not the record owners, a role or territory hierarchy still allows users higher in the hierarchy to access the records.

You can create criteria-based sharing rules for Account, Opportunity, Case, Contact, and Custom object.

For example, a custom object has been created for Newsletter. You can create a criteria-based sharing rule that shares all newsletters in which the name is set to International with the International Sales team in your organization, as follows:

Text and text area fields must be exactly specified, as they are case-sensitive. For example, a criteria-based sharing rule that specifies International in a text field would not share records with "international" in the field.

Tip

Criteria-based sharing rule with text fields

To create a criteria-based sharing rule that matches several cases of a word, enter each value separated by a comma, for example, International, international and use the contains operator.

There is a restriction on the type of field that can be used for sharing as part of the Criteria-based sharing. Along with record types, this list of fields can be set as criteria for sharing: Auto Number, Checkbox, Date, Date/Time, E-mail, Number, Percent, Phone,Picklist, Text, Text Area, URL, and Lookup Relationship (to either User or Queue).

Note

Up to 50 criteria-based sharing rules can be created per object.

Manual sharing rules

Users can manually share certain types of records with other users within the Salesforce CRM application. Some objects that are shared automatically include access to all other associated records. For example, if a user shares one of their account records, then the granted user will also have access to all the opportunities and cases connected to that account.

Manual sharing rules are generally used either on a one-off basis to share a record or whenever there is a difficulty trying to determine a consistent set of users, groups, and the associated rules that would be involved as a part of an organization-wide sharing setting. To be able to grant sharing access to a record, the user must either be the record owner, a system administrator, a user in a role above the owner in the hierarchy, or any user who has been granted full access; alternatively the OWD settings for that object must be allowed access through hierarchies.

Users grant access simply by clicking on the Sharing button found on the Record Detail page, as shown in the following screenshot:

Note

The Sharing button does not appear if the object's OWDs are set to Public Read/Write.

Manual sharing for user records

You can specify whether the Sharing button, used to grant others access to the user's own user record, is displayed on user detail pages.

To hide or display the user sharing button for all users, navigate to Setup | Security Controls | Sharing Settings. Now, click on Edit in the Organization-Wide Defaults area and scroll to the bottom of the page.

To hide or display the sharing button on user detail pages, select the Manual User Record Sharing checkbox, as shown in the following screenshot, and then click on Save.

Queues

Queues allow groups of users to manage shared records.

A queue is a location where records can be routed to await processing by a group member. The records remain in the queue until a user accepts them for processing or they are transferred to another queue.

When creating a new queue, you must specify the set of objects that are stored. Permitted objects for queues are leads, cases, service contracts, and custom objects. You must also specify the set of users that are allowed to retrieve records from the queue.

Records can be added to a queue either manually or through an automatic case or lead assignment rules.

Once records are added to a queue, they remain there until they are either assigned to a user or retrieved by one of the queue members. Here, any queue member or any user located above a queue member in the role hierarchy can take ownership of records in a queue.

Sharing access diagram

Many security options work together to determine whether users can view or edit a record. First, Salesforce checks whether the user's profile has object-level permission to access that object. Then, Salesforce checks whether the user's profile has any administrative permissions, such as View All Data or Modify All Data. Finally, Salesforce will check the ownership of the record. Here, the OWDs, role-level access, and any sharing rules will be checked to see whether there are any rules that give the user access to that record.

The following flow diagram shows you how users are affected by the different security options associated with record ownership and sharing models and rules that can be set:

In addition to the check to determine whether a user can view a record, shown in the previous screenshot, their profile (or permission set) must be set with the view permission for the relevant object.

In addition to the check to determine whether a user can edit a record, shown in the previous screenshot, their profile (or permission set) must be set with the edit permission for the relevant object.

Data validation

In the previous chapter, we looked at how we can set the required field and auto number field properties on custom fields to help improve the quality and maintain the data integrity of records in the system.

Salesforce also provides other data validation mechanisms, such as the following:

· Data validation rules

· Dependent picklists

Data validation rules

Data validation rules can be applied to both custom and standard fields and are used to verify that the data entered in a record meets the criteria you have specified before the record can be saved.

Validation rules contain a formula or expression that evaluates the data in one or more fields and returns a value of either true or false.

The logic that is used for validation rules is to seek an error condition, upon which a preconfigured error message is shown to the user whenever the formula or expression returns a value of true.

When validation rules are defined for a field or set of fields, the following actions are fired when the user creates a new record or edits an existing record and then clicks on the Save button:

1. Salesforce executes the validation rules, and only if all data is valid is the record then saved.

2. For any invalid data, Salesforce displays the associated error message without saving the record.

You can specify the error message to be displayed when a validation rule gets fired with the option to show the error message inline next to a field firing the validation rule. You can also specify where to display it. For example, your error message can be The close date must occur after today's date. You can choose to display it near a field or at the top of the page. Like all other Salesforce error messages, validation rule errors are displayed in red text and are preceded by the word Error.

Validation rules apply to all new and updated records for an object.

If your organization has multiple page layouts for the object on which you create a validation rule, you should verify that the validation rule operates as expected on each layout. Also, if you have any data integrations that affect the object, then you should also verify that the validation rule operates as intended.

Note

Even if the fields referenced in the validation rule are not visible on the page layout, the validation rules still apply and will result in an error message if the rule fails.

To begin using validation rules, navigate to Setup | Customize.

For standard objects, go to the appropriate activity, standard object, or the user's link from the menu, and click on Validation Rules.

For custom objects, navigate to Setup | Create | Objects. Now, go to the custom object.

Note

Validation rules are listed in the Validation Rules related list.

As shown, to begin adding a new validation rule, click on the New button in the Validation Rules section, as shown in the following screenshot:

Now, enter the properties of your validation rule that should include the properties detailed in the upcoming sections.

The field description section

Add a Rule Name, which is a unique identifier of up to 80 characters with no spaces or special characters such as extended characters.

The Active checkbox that is used to set that the rule is enabled.

Fill in the Description field ,which is an optional 255 character or less textbox that you can set to describe the purpose of the validation rule.

The Error Condition Formula section

The formula that is entered here forms the expression that is used to validate the field.

The Error Message section

The Error Message field is the text to be displayed to the user when a record update fails the validation rule.

Error Location is used to determine where on the page the error is displayed to the user. The options that are available are:

· Top of Page

· Field

The Top of Page option sets the error message to be displayed at the top of the page. To display the error next to a field, choose the Field option and then select the appropriate field.

If the error location is a field, the validation rule is also listed on the Detail page of that field.

You can click on Check Syntax to check your formula for errors and finally, click on Save to finish or Save & New to create additional validation rules.

As an example, the following formula text shows you an opportunity validation rule to ensure that users cannot enter a date in the past into the Close Date field.

The formula would be CloseDate < TODAY()

Note

If the error location is set to a field that is later deleted or a field that is read-only or not visible on the page layout, Salesforce automatically changes the error location to Top of Page.

An example error message for this validation rule is Close Date Must Be a Future Date.

Dependent picklists

Dependent picklists help make data more accurate and consistent by applying filters.

A dependent field works in conjunction with a controlling field to filter its values. The value chosen in the controlling field affects the values in the dependent field.

In the following screenshot, we see the Speaker Status field being controlled by the Speaker Event Status field:

Dependent and controlling picklists

Dependent and controlling picklists work in conjunction where the value chosen in the controlling picklist dynamically changes the values that are available in the dependent picklist.

Both controlling and dependent picklists are indicated on the edit pages by an icon. By hovering the mouse over these icons, users can see the name of the controlling or dependent picklist.

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

For standard objects, navigate to Setup | Customize. Now, select the appropriate object from the Customize menu and click on Fields.

For custom objects, navigate to Setup | Create | Objects. Now, select one of the custom objects in the list.

For custom task and event fields, navigate to Setup | Customize | Activities | Activity Custom Fields.

Now, click on Field Dependencies in the Custom Fields & Relationships section, as shown in the following screenshot:

Now, click on New to navigate to the New Field Dependency screen and then choose Controlling Field and Dependent Field, as shown in the following screenshot:

Click on Continue to display the next screen where you are presented with a field dependency matrix to specify the dependent picklist values that are available when a user selects each controlling field value.

The field dependency matrix lets you specify the dependent picklist values that are available when a user selects each controlling field value. The top row of the matrix shows you the controlling field values while the columns show you the dependent field values.

Using this matrix, you can include or exclude values. Included values are available in the dependent picklist when a value in the controlling field is selected and excluded fields are not available.

Here, you can include or exclude values by performing the following steps:

1. Double-click on values to include them. The included values are then indicated with a highlight. (Double-clicking again on any highlighted values will exclude them).

2. To work with more than one value, you should use the Shift key and click on each value to select the required range of values, as shown in the following screenshot:

3. After selecting the values, click on Include Values to make the values available, or click on Exclude Values to remove them from the list of available values.

You can also use the Ctrl key and then click on the individual values to select multiple values. Again, clicking on Include Values makes the values available, or clicking on Exclude Values removes them from the list of available values. By clicking on a column header, you can select all the values in that column as follows:

To change the values in your view, you can:

· Click on View All to view all available values at once

· Click on Go To and choose a controlling value to view all the dependent values in that column

· Click on Previous or Next to view the values in columns that are on the previous or next page

· Click on View sets of 5 to view five columns at a time

Now, optionally, click on Preview to test your selections and then click on Save.

Dependent picklist considerations

There are various restrictions associated with the creation and configuration of dependent and controlling picklist fields that should be considered.

The following are the dependent picklist considerations:

Controlling fields

The following restrictions should be considered for controlling fields:

· Checkbox fields can be controlling fields

· Multiselect picklists cannot be controlling fields

· There is a maximum of 300 values allowed in a controlling field

Dependent fields

The following restrictions should be considered for dependent fields:

· Multiselect picklists can be dependent picklists

· Checkboxes cannot be dependent fields

Standard picklist fields

Standard picklist fields cannot be defined as a dependent list. They can only be set up as a controlling field.

Default values

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

Converting fields

When converting existing fields to dependent picklists or controlling fields, this can be done without affecting the existing values in records. Only for changes going forward are the dependency rules applied to the updates to existing records or new records.

Field-level security

Field-level security settings for a controlling field and the dependent picklist are completely independent. Therefore, you must manually hide a controlling field whenever its related dependent picklist is hidden.

Page layouts

For best practice and improved user visibility, make sure the dependent picklist is lower on the page layout than its controlling field.

If a dependent picklist is required and no values are available for it based on the controlling field value, users can save the record without entering a value. In this scenario, the record is saved with no value for that field.

Note

Make sure controlling fields are added to any page layouts that contain their associated dependent picklists. If the controlling field is not on the same page layout, the dependent picklist shows no available values.

Record types

The values in controlling fields are determined by the preselected record type and the values in dependent picklists are determined by both the record type and the selected controlling field value.

The values available in dependent picklists are, therefore, an intersection of the preselected record type and the subsequent controlling field selection.

Importing data

The data import utilities do not consider field dependencies. Therefore, any value can be imported into a dependent picklist field regardless of the value imported for a controlling field.

An overview of data import and export utilities

Salesforce provides data utilities that are available for the import and export of data to and from Salesforce. There are also a wide variety of third-party tools that allow data to be imported and exported from Salesforce and use the publicly available Salesforce APIs to provide data integration.

The third-party data import and export tools are not supported by Salesforce; therefore, we will not be covering these in this book but you can find information about them on the Internet.

Looking at the available Salesforce supported facilities to import and export data, we have the following specific options:

1. Data Import Wizard

2. Individual Import Wizards:

· Import Accounts/Contacts

· Import Leads

· Import Solutions

· Import Custom Objects

3. Data Loader

Data Import Wizard

The Data Import Wizard opens in a full browser window and provides a unified interface that lets you import data for a number of standard Salesforce objects, including Account, Contact, Lead, Custom Object, and Solution.

Individual import wizards

The Salesforce individual import wizard opens in small pop-up window and presents an easy-to-use multistep wizard to import new Account (Person and Business Accounts), Contact, Lead, Custom Object, or Solution records into Salesforce.

The wizard can also be used for Account (Person and Business Accounts), Contact, Lead, Custom Object, or Solution updates based on a matching identifier.

Note

Contact and Lead can be updated by matching the e-mail address, and Custom Object or Solution can be updated based on custom object names, solution titles, Salesforce Id, or an external ID.

A Comma Separated Value (CSV) file format is required when using an import wizard where import wizard imports are limited to 50,000 records per session.

Note

Account and Contact import wizards have a built-in de-duplicating functionality. Account can be matched using the account name and account site. For contacts, de-duplicating matching can be carried out using the first name, last name, or e-mail address.

At the time of writing this, Salesforce.com is planning to replace the individual import wizards with the unified Data Import Wizard.

Data Loader

The Data Loader is a client application from Salesforce for bulk import or export of data.

When importing data, the Data Loader loads data from CSV files or from a database connection, and the exporting of data is done using CSV files.

Data Loader and import wizards compared

With the Data Loader, you can perform operations such as insert, delete, update, extract, or upsert. You can move data into or out of any Salesforce object. There is less validation when adding data.

The import wizards have fewer options and are more limited as they only support Account, Contact, Lead, Solution, and Custom object. They have built-in de-duplication logic.

Use the Data Loader when:

· You need to load 50,000 or more records where the maximum is 5 million records

· You need to load into an object that is not yet supported by web-based import wizards

· You want to schedule regular data loads, such as nightly imports

· You want to save mappings for later use

· You want to export your data for backup purposes

Use web-based import wizards when:

· You are loading fewer than 50,000 records

· The object you need to import is Account, Contact, Lead, Solution, and Custom object

· You want to prevent duplicates by uploading records according to the account name and site, contact e-mail address, or lead e-mail address

Note

If you're logging in from an IP that's not in the trusted range, you must add a security token as described in the earlier chapter.

Best practices for mass data updating

When carrying out any kind of mass data update or deletion in Salesforce CRM, you should ensure that the data to be changed is correct, of course, but you should also consider applying the best practices discussed in the upcoming sections:

Tip

Back up your data

Back up your data before performing a mass update or delete it by either requesting a data export or exporting your own report of the data.

Always include both the Date/Time Stamp and Created by Alias criteria in your mass delete to ensure that you are only deleting your imports and no one else's data.

Weekly export

Your organization can sign up to receive backup files of your data. You can export all of your organization's data into a set of CSV files.

Note

The weekly export service can only be enabled by sending a request to Salesforce customer support.

With the data export feature, you can generate backup files manually once every six days or schedule them to generate automatically at weekly or monthly intervals.

When the export is ready, you will receive an e-mail with a link; navigate to the link provided.

To schedule a weekly export, navigate to Setup | Data Management | Data Export. Now, click on either the Export Now or Schedule Export buttons.

The Export Now option prepares your files for export immediately. This option is only available if a week has passed since your last export. The Schedule Export option allows you to schedule the export process for weekly or monthly intervals.

Field sets

Field sets combine the power of Visualforce to create custom user interface pages with what has always been a defining trait of the Force.com platform: the ability for administrators to customize the application using config over code.

A field set is a grouping of fields. For example, you could have an account search Visualforce page that uses a field set to control which account fields are returned in the search results. When a field set is added to a Visualforce page, developers can loop over its fields and display them. The same Visualforce page can therefore be used to present a different set of information, depending on which fields you wish to render.

Field sets enable you to customize the fields that appear on a custom Visualforce page using a simple drag-and-drop interface to add, remove, or rearrange fields from the field set without altering the Visualforce page, as shown in the following screenshot:

When a field is included in the Available for the Field Set section, it exists in the field set, but it will not be rendered on the Visualforce page. You can display the field by moving it from the Available for the Field Set column to the In the Field Set column.

When a field is marked as In the Field Set, the field will be rendered on the Visualforce page. You can remove the field from the page by removing it from the In the Field Set column.

Folders

Folders are used to organize e-mail templates, docs, reports, and dashboards. Folder access is specified as read or read/write, which is explicitly set for the folder, and there is no rolling up of user permission to access using the role hierarchy. Only one type of media can be stored per folder; it is not possible to mix the types of files that are stored.

Recycle Bin

Recycle Bin can be accessed from the Home tab by clicking on the link in the sidebar, as shown in the following screenshot:

Recycle Bin is where the deleted data is stored and from where it can be accessed for 15 days, after which the data becomes hard deleted and is no longer recoverable.

Clicking on Recycle Bin allows you to view both your deleted items plus your organization's deleted items, as shown in the following screenshot:

You can use the Empty your recycle bin button to permanently remove deleted items prior to the 15-day expiration.

Note

Records in Recycle Bin do not count against your organization's storage limits.

To calculate the number of records that your recycle bin can store, Salesforce uses this formula: 25 multiplied by the number of Megabytes (MB) in your storage.

For example, if your organization has 1 GB, which equates to 1000 MB (a 1000 MB storage unit is used here and not 1028 MB), then your limit is 25 multiplied by 1000 MB, which equals 25,000 records.

When your organization reaches the Recycle Bin limit, the Salesforce CRM application automatically removes the oldest records (if they have been in the Recycle Bin for at least two hours).

Data storage utilization

Salesforce CRM has two categories of storage, namely data—used to store records (for example, Opportunity, Account, or Custom object data records)—and file storage—used to store file attachments (for example, presentations, spreadsheets, images, or Adobe PDFs, and so on).

As a minimum, Salesforce CRM (Enterprise Edition) provides 1 GB for data storage and 11 GB for file storage. In total, this 12 GB storage amount (1 GB for data plus 11 GB for files) is the minimum total storage allocated for a Salesforce CRM organization. However, the storage amount increases as more active users are added, as there is also a 20 MB per user limit for data and 2 GB per user for file storage.

As an example, an organization with 500 active users sees the storage amount for data increase to 10 GB. This is calculated as 500 (users) multiplied by 20 MB, which equals 10,000 MB or 10 GB. The storage amount for files is increased to 1,000 GB (500 users multiplied by 2 GB)

To view your organization's used data space and used file space, navigate to Setup | Data Management | Storage Usage.

You can view the limits and used amounts for data and file storage, the amounts in use per record type, and the current file storage usage. You can also view the top users of data and file storage. To see exactly what is being stored by the listed users, you can click on that user's name.

Summary

In this chapter, we described the ways in which permissions to access data records in Salesforce are controlled by objects and profile permissions along with OWDs.

We looked at how access to records could be further widened through the use of Permission Sets, Sharing Rules, criteria-based sharing, and manual sharing. The mechanisms that are available to help manage the quality and integrity of data were covered, and we looked at data validation rules and dependent picklist fields. We also learned about options for importing and exporting data using the various import wizards for smaller fragments of data and the Data Loader for larger volumes of data.

In the next chapter, we will be covering Data Analytics, where we will see how we can report on the data in Salesforce. Also included in the next chapter is the setting up of reports, dashboards, custom reports, and the use of the Report Builder.