Salesforce.com Application Sharing Model
All users and application level security is defined and maintained by the organization administrator, and not by salesforce.com. The organization administrator is appointed by your organization.
Sharing Model Elements:
Profiles
Roles
Hierarchy
Record Types
Page Layouts
Field Level security
An organization’s sharing model sets the default access that users have to each others data. There four sharing models:
Private:
Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records. For example, if Tom is the owner of an account, and he is assigned to the role of Western Sales, reporting to Carol (who is in the role of VP of Western Region Sales), then Carol can also view, edit, and report on Tom’s accounts.
Public Read Only:
All users can view and report on records but not edit them. Only the owner, and users above that role in the hierarchy, can edit those records.
For example, Sara is the owner of ABC Corp. Sara is also in the role Western Sales, reporting to Carol, who is in the role of VP of Western Region Sales. Sara and Carol have full read/write access to ABC Corp. Tom (another Western Sales Rep) can also view and report on ABC Corp, but cannot edit it.
Public Read/Write:
All users can view, edit, and report on all records. For example, if Tom is the owner of Trident Inc., all other users can view, edit, and report on the Trident account. However, only Tom can alter the sharing settings or delete the Trident account.
Public Read/Write/Transfer:
All users can view, edit, transfer, and report on all records. Only available for cases or leads. For example, if Alice is the owner of ACME case number 100, all other users can view, edit, transfer ownership, and report on that case. But only Alice can delete or change the sharing on case 100.
Profiles:
A profile defines a users permission to perform different functions within salesforce.com. Profiles also control the following:
– Which page layouts the user sees
– The field-level security access that the user has to view and edit specific fields
– Which tabs the user can view
– Which record types are available to the user
– The hours and IP addresses from which the user can log in
– Administrators, and users with the “Manage Users” permission, can create, edit, and delete profiles
Notes on User Roles:
Every user must be assigned to a role, or their data will not display in opportunity reports, forecast rollups, and other displays based on roles.
– All users that require visibility to the entire organization should be assigned the highest level in the hierarchy.
– It is not necessary to create individual roles for each title at your company, rather you want to define a hierarchy of roles to control access of information entered by users in lower level roles.
– When you change a user’s role, any relevant sharing rules are reevaluated to add or remove access as necessary.
Record Types:
– If your organization uses record types, edit the record type to modify which pick list values are visible for the record type. You can set default pick list values based upon the record type for various divisions.
Field Level Security:
Field-level security settings let administrators restrict users. access to view and edit specific fields on detail and edit pages and in related lists, list views, reports, Offline Edition, search results, email and mail merge templates, Custom Links, and when synchronizing data.
The fields that users see on detail and edit pages are a combination of page layouts and field-level security settings. The most restrictive field access settings of the two always apply. For example, if a field is required in the page layout and read-only in the field-level security settings, the field-level security overrides the page layout and the field will be read-only for the user.
