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.

User Groups

Record-level sharing operates on groups of users, not individual users. Force.com provides
two mechanisms for grouping users relevant to sharing: Public Groups and Roles.

Public Groups

At its simplest level, a public group is a named list of users included in the group.This list
can also contain other public groups.To define a public group, click Setup. In the Administration
Setup area, click Manage Users -->Public Groups.
A best practice for public groups is to keep the membership list as short as possible.
This improves performance and simplifies maintenance. Build larger groups up from
smaller subgroups rather than working with individual users.

Roles

Roles are also groups of users but are organized in a hierarchy. Users in roles can inherit
the privileges of the roles below them in the hierarchy.This includes record ownership.
A user belongs to one role at a time, and all applications in your Force.com organization
use a single role hierarchy.

To define roles, click Setup. In the Administration Setup area, click Manage Users -->
Roles.The first time you use this feature, Force.com asks you to select a sample set of
roles to get started.

Record Ownership

When a new record is created, it’s owned by the user who created it.The owner has full
control over the record.The owner can read, edit, and delete the record; share with other
users; and transfer ownership to a different user.
You can experiment with record ownership by creating a record in the native user
interface and examining its detail. Notice that its owner field is set to your user, the user
creating the record.To share the record with others, click the Sharing button.To transfer
ownership, click the Change link beside the owner name.
Owners are typically individual users, but a queue can be also an owner.A queue is a
holding area for records to which users are assigned.When a user takes ownership of a
record in queue, it leaves the queue and is assigned directly to that user.To configure
queues, go to the Administration Setup area and click Manage Users ➝ Queues.
Most objects support record ownership.The notable exception is child objects in a
Master-Detail relationship. Records in these child objects have no owners.They inherit
ownership from their parent records.

Record-Level Security

In Force.com, individual data records within an object are secured through a combination
of three concepts:
1. Record Ownership: All records except those on the child side of a Master-Detail
relationship have a single named owner. Record owners are individual users or
groups of users. Ownership of a record can be transferred manually to another user
or group.
2. User Groups: Users can be organized into flat lists and placed in a hierarchy.
Groups can contain individual users as well as other groups.
3. Sharing Model: The sharing model consists of two parts, organization-wide
defaults and sharing reasons.The organization-wide defaults can be configured to
lock down all records by object, regardless of their owner. Sharing reasons selectively
override the defaults to allow access based on record ownership or arbitrary
criteria.

Field-Level Security

Security of fields is determined by a combination of the profile and the page layout.The
more restrictive of the two always takes precedence.The two ways to edit field-level security
are through the profile directly using the Field-Level Security section or through a
feature called Field Accessibility. Field Accessibility is a bit more sophisticated because it
provides a consolidated view of fields across page layouts and profiles.

Field-Level Security in Profiles

To reach the field-level security section, click Setup, and in the Administration Setup area,
click Manage Users --> Profiles. Select a profile by clicking its name and scroll down to
the Field-Level Security section. Click the View link next to the object name, such as Project.


The two possible states for a field are visible and read-only. Fields marked as visible are
available for display on page layouts belonging to this profile. Read-only fields might also
be visible on a page layout, but values in these fields cannot be modified.

Field Accessibility

Field Accessibility addresses the finer control of fields provided through the combination
of page layout and profile.The more restrictive of two settings always wins. So, if a page
layout defines a field as read-only that is defined in the profile as being invisible, the profile
takes precedence, and the field is hidden. Field Accessibility provides an easy way to
see this behavior in action.
To use Field Accessibility, click Setup, and in the Administration Setup area, click
Security Controls ➝ Field Accessibility. Select an object and then drill in by Field or Profile
to see the corresponding field accessibility table. Each field has one of four accessibility
values:
 Required: If a field is defined as required in its page layout and visible in its profile,
it is a required field.This means for a record to be saved, it must contain a value
for this field.
 Editable: A field defined as visible in both the page layout and the profile is designated
as editable.This field appears to the user and can be modified.
 Read-Only: If a field is declared read-only on its profile or visible in its profile and
read-only in its page layout, then it is a read-only field. It appears in the page layout,
but its value cannot be modified.
 Hidden: Fields that are set to invisible on their profile or page layout are hidden.
Hidden fields are never shown to the users of this profile.
Try marking a field as read-only in its page layout but invisible in its profile.Then hover
the cursor over the word Hidden in the Field accessibility table.You’ll see the message that
the field is hidden because of Field Security. If you edit the field again and make it visible
via the profile, the field becomes read-only per the page layout.

Licensing

Profiles are associated with a user license. Licenses are how Salesforce charges for the
Force.com platform when you’re ready to go into production with an application. Salesforce
has many license types to provide flexibility in pricing, but the most basic licenses
are Salesforce and Salesforce Platform.The Salesforce Platform license allows full use of
Force.com but disables the business domain-specific functionality such as CRM or SFA.
For example, a Salesforce license grants you the use of the Opportunity and Case objects,
but a Salesforce Platform license does not. Sometimes even infrastructure features are
downgraded. For example, profiles for a full Salesforce license can delegate administration
on standard and custom objects.The Salesforce Platform license limits this feature to custom
objects only.
Planning ahead pays in regard to licensing Force.com. If you are sure you do not need
the extra features of the Salesforce license, select the Salesforce Platform license for your
profiles.This cuts down on the number of objects and features you see during development
and prevents you from accidentally referencing one of them.Also, in order to assign
a user to a profile, that user must have a user license that matches the profile.Your custom
profile cannot be associated with a different license after it has been created.

Object-Level Security

Object-level security is governed by the profile. Profiles control data access for a group of
users on the level of objects and fields.This section describes profiles and how they are
configured.

Profiles

Profiles are the primary way to customize the Force.com user experience.They contain a
large number of settings to control the user interface and data security of your organization.
Users are assigned to profiles based on the tasks they need to perform in your system.
The two types of profiles are standard and custom. Standard profiles are provided with
Force.com and cannot be renamed or deleted, although they can be reconfigured. Custom
profiles have the same functionality as standard profiles but can be named.They can
also be deleted if no users are assigned to them.
To manage profiles, click Setup, and in the Administration Setup area, click Manage
Users ---> Profiles. In the realm of data security, the two primary sections to focus on are
Administrative Permissions and Object Permissions.

Tip

Make sure Enhanced Profile List Views are enabled for your organization. This feature allows
up to 200 profiles at a time to be compared and modified easily, with far fewer clicks than
the default user interface. To enable it, click Setup, and in the App Setup area, click Customize
----> User Interface and select Enable Enhanced Profile List Views.

Administrative Permissions

Two administrative privileges in a profile trump all other security features in Force.com:
Modify All Data and View All Data. Users of a profile with these permissions can modify
and view all records of all objects, overriding all Force.com security measures.These permissions
are powerful, so grant them with extreme care in a production environment.
Developers need these permissions to work with tools such as the Force.com IDE, but
this applies only in a sandbox or development environment.

Object Permissions

Object permissions are divided into two sections, one for standard objects and another for
custom objects.They have identical functionality. Note that object permissions cannot be
edited on standard profiles. Figure 3-3 shows the section of a custom profile that defines
object permissions.
Each object name is followed by a row of check boxes. Each check box corresponds to
a permission for that object.The permissions are described in the following list:
> Read: The Read permission allows users to view records of this object. Unless
overridden with field-level permissions, this access applies to all fields of the object.
> Create: The Create permission permits Read access and the addition of new
records to the object.
> Edit: The Edit permission allows records in this object to be read and modified.
> Delete: This permission enables users to read, edit, and remove records from this
object. Deleted records are moved to the Recycle Bin, where they can be
undeleted or permanently erased.
> View All: The View All permission is like the system-wide View All administrative
permission but scoped to a single object. It’s designed for use in exporting data
because it circumvents other security features of the platform, ensuring that all
records are accessible.
> Modify All: Like View All, this permission is intended for bulk data operations
such as migration and cleansing. It allows users to modify all fields of all records in
this object, overriding every other security measure.

New custom objects initially have all permissions disabled for all profiles, except those
with View All Data or Modify All Data permission.This platform behavior of defaulting
to the most secure configuration ensures that your data is not unintentionally exposed.