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.