Defining Record Types

Record types are defined at the object level after an object is created. In the object definition
is a section called Record Types for creating, editing, and deleting record types. Click
the New button there to start.

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

The list at the bottom of the page is a shortcut for adding this record type to many
profiles at once.You can skip it. If you do use it, do so with caution. If you add your
record type to many profiles and later decide you want to delete it, you must manually
visit each profile to remove the record type first. Record types cannot be deleted if they
are referenced by profiles.

The next page allows you to associate your new record type with one or more page
layouts.This determines which native user interface is shown when a user creates or edits
a record of this type.The default is to show one page layout to all users, regardless of their
profiles.This page can also be skipped.There is another user interface to do the same
thing, but across multiple record types and profiles simultaneously.

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


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

How to disable a Record Type in Salesforce

How to disable a Record Type in Salesforce

How to disable a Record Type in Salesforce Using record types you can provide different sales/business processes to your users with different picklist values and different page layouts.

When creating a new record type you can choose if you want to enable it for one or several profiles. If you enable it, it will (if more than one are enabled ) appear as a choice that comes up before you create a new object.

Let’s take the Opportunity as an example. I need three record types and first I decide to have all three enabled, i.e. to have as choices in the beginning of a creation of an object instance.

Find the record types for the Opportunity here:



When you are creating a new record type you get the option to enable it for all or some profiles. If they are enabled they will appear as choices as explained before. Important though is thay they have to be active. If they are not active they can not be used.



Now we have three record types for the Opportunity:



And in the profile for the Contract Manager for example we can see that three Opportunity Record Types has been enabled.



To disable a record type from only one or some profiles you can simply click on edit and select or deselect which should be available.



But if you want to disable a record type from all profiles and don’t want to go through the work of entering each profile separately you simply open the record type and inactivate it. This way it will automatically be disabled and removed as selected from the profiles.




If you want to enable a record type again though after this you don’t seem to get the same option as when first creating the Record Type, i.e. to enable for one or several profiles at once. Instead you would have to enter each profile separately and reselect it again.

Record Types

Record types overload the native user interface behavior of a single object.This allows
you to get more mileage out of your existing objects or limit the complexity of a new
data model.

For example, Salesforce uses this feature in its CRM product. Person Accounts are a
record type of the Account object.Accounts ordinarily store information about businesses,
but the Person Account record type adapts Account to store information about
individuals. Salesforce opted to overload Account with a record type rather than creating
an entirely new object.
Before creating a separate object to represent every business entity, ask yourself
whether the entity is truly new or merely a slight variation of another entity.Where you
find slight variations, consider using a single object to do the work of many.The single
object contains a superset of the objects’ fields.The record type of each record determines
which variation of the business entity is stored. Force.com consults the record type and
the user’s profile to display the correct native user interface.
Even if you don’t plan to use the native user interface, record types can expand the
flexibility of your data model. By using record types, you gain an additional standard field
called RecordTypeId. In custom user interfaces, you can use this to drive different functionality.
Of course, you can always add your own custom field to accomplish the same
thing, but record types force you to make your design explicit at the native Force.com
level and provide tight integration with native Force.com security.
Record types can be tricky to configure because they interact with many other features
of Force.com.This section examines record types across three areas:
1. Defining Record Types: Record types enable picklist fields to be customized to
show different values for different record types of an object.They also add another
dimension of flexibility when designing page layouts.
2. Securing Record Types: Users gain access to record types through their profiles.
3. Using Record Types: The native user interface changes in some significant ways
when a user has rights to multiple record types.

Dependent Fields

Dependent fields are primarily used to define cascading picklists. Cascading picklists are a
user interface pattern in which the values in one picklist depend on the selection in
another picklist. For example, a picklist for state/province might depend on another picklist
for country.When a user selects a country, the state/province picklist is populated with
a set of values that make sense given the selected country. In Force.com, the first picklist is
called the dependent field, and the second is the controlling field.The controlling field
can be a standard or custom picklist (with at least 1 and fewer than 300 values) or a check
box field, but cannot be a multi-select picklist.The dependent field can be a custom picklist
or multi-select picklist.

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

1. Navigate to the Custom Field Definition Detail page for the dependent field.
2. In the Picklist Options subsection, click the New link next to the label for Controlling
Field.
3. Select the controlling field and click the Continue button.
4. Use the grid to specify which values of the controlling field should be included in
the dependent field. Picklist values of the controlling field are shown as columns.
Values of the dependent field appear as rows. Double-click individual values to
include or exclude them or hold down the Shift key while clicking multiple values
and click the Include Values and Exclude Values buttons to make changes in bulk.

Dependent fields can be challenging to incorporate in dynamic user interfaces and are
not supported in Force.com Connect Offline.The main alternative to dependent fields is
a Lookup relationship between two objects that contain your valid values. If you already
have an investment in picklists and want to migrate, create two objects. One object contains
the values of the controlling field; the other contains the dependent field’s values.
Add a lookup relationship field on the second object, relating it to the first. Load the first
object with records, one for each of the controlling field’s picklist values.Then add
records to the second object, assigning them the correct parent controlling record.

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

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

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


Field History Tracking: Field History Tracking is an audit trail for your objects.
As records are updated, details of the changes are stored in a separate history object.
Details include the user modifying the record, the fields modified, and the old and
new values.


Tags:Tags are an alternative way to search for records.They are user-created,
informal annotations of records that can be easily searched and shared to drive
collaboration.

Force.com Connect Offline: This feature brings portions of your Force.com
database directly to your desktop.You can work disconnected from the Internet,
and your data is synchronized with Force.com when you reconnect.

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

Sample Application: Three of the preceding features are applied to enhance the
Services Manager sample application.

Sharing Reasons

Sharing reasons override the organization-wide defaults to allow individual records to be
shared between groups of users.The groups can be roles or public groups.The behavior
of the sharing reason depends on the groups involved and the type of sharing reason.
Sharing between roles results in asymmetric privileges. Users in subordinate roles do
not receive any privileges of their superiors, but superiors receive all the privileges of
their subordinates. Sharing with public groups is symmetric, granting equal rights to both
parties. In other words, a user has access to all records that are accessible to its descendants
in role hierarchy. For example, the SVP of Customer Service & Support
has access to records that are accessible to Customer Support, International and Customer
Support, North America.
The four types of sharing reasons are as follows:
1. Manual: The owner of a record can elect to manually share it with another user or
group of users.The owner specifies the level of access (Read Only or Read/Write)
to be granted.To configure manual sharing, click the Sharing button on a detail
record in the Force.com native user interface. Figure 3-7 shows the user interface
for sharing a record named GenePoint in the Project object.

2. Sharing Rules: Sharing rules allow records to be shared automatically by
Force.com based on group membership or arbitrary criteria. In Figure 3-8, a sharing
rule is being created for the Project object. It specifies that members of the
Central business unit can automatically read and write all Project records owned by
their colleagues in the same business unit. In Figure 3-9, a criteria-based sharing
rule is being defined to provide users in the Executive role with read and write
access to billable projects.
3. Procedural: Records can be shared programmatically using Apex code.This allows
a developer to define the conditions that govern the sharing of a record.
4. Delegated Administration: Profiles contain a special object permission category
called Data Administration. It contains View All and Modify All permissions. If these
are granted, they exempt users in that profile from all sharing rules, giving them
access to all records regardless of owner.This privilege is intended for data import,
export, and cleansing programs that need to run unencumbered by sharing rules.

Sharing Model

The sharing model defines how record-level privileges are granted to users who do not
own the record. Configuring the sharing model is a two-part process. Organization-wide
defaults are used to establish the most restrictive level of access for each object. Sharing
reasons override the defaults to grant access to individual records.
Organization-Wide Defaults
Every object that allows record ownership has an organization-wide default setting dictating
how records are shared between the owner and other users. Custom objects have
several default settings:
Private: Records belong to the owner and only the owner.With the exception of
the data administration-level privileges View All and Modify All, records are accessible
only to their owners.
 Public Read-Only: Any user can view records in this object but cannot edit or
delete them. Only the owner and users with administrative privileges have rights to
edit and delete.

 Public Read/Write: Any user can view, edit, and delete records in this object. All
newly created custom objects default to this setting.
Controlled by Parent: This option is available only to child objects in Lookup
relationships. It delegates record-sharing decisions to the parent record.The child
records behave as if they lack an owner. Objects with this default setting have the
same record-sharing behavior as children in a Master-Detail relationship.

When setting organization-wide defaults, begin with the user to receive the minimum
access to data. Set the organization-wide default settings with this user in mind. All users
then have at least this level of access to records.
To configure organization-wide defaults, click Setup. In the Administration Setup area,
click Security Controls -->Sharing Settings.


The rightmost column of check boxes called Grant Access Using Hierarchies determines
whether the role hierarchy is used on this object to propagate permissions upward
to superior roles. By default, this behavior is enabled. Disabling it causes roles to function
like public groups. Record permissions are shared only between a pair of roles, never
aggregated up the role hierarchy.