Introduction to record ownership, profiles, and sharing
Before looking at the features available to manage users, we start with a brief introduction to the concepts of record owner, profiles, and sharing in Salesforce CRM.
Record owner
The terminology "record owner" is reflected throughout Salesforce and for each and every data record there can be one and only one record owner.
Only users that are active in Salesforce can have records assigned to them.
When a user is marked inactive in Salesforce CRM, he/she no longer has access to the application. However, any records that this inactive user owns remain in the application and continue to show the inactive user as the record owner.
The record owner setting generally determines if access to that record is available to other users within the organization, and is enabled using either profile or sharing settings.
Profiles and sharing
Profiles, sharing, and the optional role hierarchy setting work together and should be considered as a whole when setting up record ownership and data access for users. An overview of the relationship between users, profiles, and the sharing settings can be pictured as follows:
All users in Salesforce must be assigned a profile. The profile is a control mechanism used to determine which functions the user can perform, which types of data they can access, and which operations they can carry out on that data.
All users are associated with sharing mechanisms in Salesforce, which determine the actual records the user can access. Controlling the level of record access can be achieved using options ranging from default sharing, which is set at the organization level, to role hierarchy and beyond using advanced sharing mechanisms. A user does not have to be assigned to a role in Salesforce.
The sharing rules are briefly outlined as follows and covered in far more detail later in this book.
Profiles
Some of the key controls of the profile are to identify the type of license specified for the user, any login hours or IP address restrictions, and control access to objects. If the appropriate object-level permission is not set on the user's profile, the user will be unable to access the records of that object type in the application.
Profiles never override your organization's sharing model or role hierarchy. For example, a profile may be set to allow a user access to create, edit, and delete leads. However, a user with this profile cannot edit or delete other users' leads if your organization's lead sharing model is read only.
In the next chapter, we will look in detail at the features that the profile controls, which include tabs, object-level security, field-level security, Apex/Visualforce page accessibility, console layout, application selections, and administrative and general user permissions.
There are two types of profile in Salesforce—standard and custom—with each standard or custom profile belonging to exactly one user license type.
Standard profiles and custom profiles are similar in nature. The difference being that for standard profiles, the following settings cannot be applied: administrative permissions, general user permissions, and object-level permissions, plus notably the Password Never Expires setting, which means you are not required to change your password after a certain amount of time (this is a part of the password policies, which are described later). Hence, you must create a custom profile if you want to enable any of these features.
There are six standard profile types which are as follows:
- Contract manager
- Marketing user
- System administrator
- Solution manager
- Standard user
Note
Read-only standard profiles have their uses, but it is wise to limit that use to cloning them to create custom profiles. It is not unknown for Salesforce to change the settings for standard profiles when a new release is rolled out, which can result in an undesired outcome for any user assigned with that profile.
Sharing
Sharing settings control the default access for each object across the organization. Sharing rules per object can grant access beyond the default sharing settings; they cannot restrict access. The default sharing settings are as follows:
- Controlled by Parent
- Private
- Public Read Only
- Public Read/Write
- Public Read/Write/Transfer
- Public Full Access
- Grant Access Using Hierarchies
When the Grant Access Using Hierarchies setting is enabled, the role of the record owner determines visibility throughout the organization. Users in higher roles in the hierarchy will have full access (view/edit/delete) to all records owned by those at a lower level in the role hierarchy.
If Grant Access Using Hierarchies is not enabled, all roles are treated equally regardless of the hierarchy.
Note
Grant Access Using Hierarchies is only applicable for custom objects since they cannot be disabled for standard objects.
Roles
Roles are the principal elements in sharing rules. Users can be grouped into roles based upon their need for access to data, according to how they fit into the role hierarchy. Creating a role for every user's job title is not required.
Roles are accessed throughout the application and are particularly important for reporting. For instance, if you have two departments, "Operations" and "Sales", you can run comparative reports on both roles.
Roles generally report to another role and are used to maintain the role hierarchy. It is a one-to-many hierarchical relationship with the hierarchy, allowing managers to see the data of the users that report to them. 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.
Note
You can create up to 500 roles for your organization.
Role hierarchies do not need to specifically match your organization chart. Instead, each role in the hierarchy should represent a level of data access required by users.
Permission sets
Permission sets allow you to further control access to the system for the users in your organization. They can be considered as a method to fine-tune the permissions for selected individuals and enable access in a similar way to the setting up of profiles.
Note
Permission sets allow you to grant further access but not to restrict or deny access.
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 called Convert Leads that provides the facility for converting and transferring the leads and assign it to a user who has a profile, which does not provide lead conversion. You can create a permission called Edit Contacts and assign it to a user who has a profile that does not provide contact editing. You can also group these permissions into a permission set to create specific profile-like permissions without actually having to create or clone complete profiles, which are often unnecessary.
Note
You can create up to 1,000 permission sets for your organization.
Permission sets are an ideal mechanism to apply system access for your users without affecting all other users that have the same profile and without having to create one-off profiles, which sometimes lead to an increase in the amount of maintenance.
A common use for permission sets is to grant additional permissions in addition to the settings listed in a profile to individuals without changing their profile. For example, to provide more rights than their profile currently allows.
Creating Permission sets
To create a permission set, navigate to Your Name | Setup | (Administration Setup) | Manage Users | Permission Sets. Click on New. Enter a label, API name, and description.
Note
If you plan to assign the permission set to users that all have the same type of user license, a best practice is to associate that user license with the permission set. However, if you plan to assign the permission set to users that currently have different licenses (or may have different licenses in the future), it is probably best to create an organization-wide permission set.
To continue creating the permission set (as outlined previously), either select a user license or select the option --None-- (to create an organization-wide permission set). Now finally, click on Save.
Note
When you clone an existing permission set, the new permission set has the same user license and enabled permissions as the permission set it is cloned from.
