Profile is a collection of settings and permissions that define what a user can access in Salesforce. A profile controls:
- Object Permissions
- Field Permissions
- User Permissions
- Tab Permissions
- App Settings
- App Class Access
- Visual force Page Access
- Page Layouts
- Login Hours
- Login IP ranges
- Record Types
Setting up and managing profiles is a way by which you can conventionally create a secure boundary that dictates user’s access rights.
The Profile is mandatory for every user in Salesforce. Profiles authorizations control object and field-level access permissions of a client. Indeed, a client cannot be characterized without being doled out to a particular profile, since the profile indicates an essential access for clients.
- Standard profiles: Bye default, Salesforce provides Standard profiles which cannot be deleted. These are:
- Read only
- Standard User
- Marketing User
- Contract manager
- Solution Manager
- System Administrator.
Each and every standard profile include default set of permissions for all standard objects available on the platforms.
- Custom Profiles: These are the profiles which can be created by the user and can be deleted or altered as per the business need.
Navigation -> Setup -> Administrator -> Manage users -> Profiles
Fig 1. Profiles
Profile controls all the following permissions:
- Object permissions [create, delete, read, edit permissions]
- Field permissions [view, edit]
- Record type permission
- Which Apps can be seen
- Login hours can be defined
- IP address permissions
- Which tabs are visible
- Which page layouts can be viewed
- Classes, pages permissions
Permission Sets extend user’s functional access without changing their profiles. One can grant as many permission sets to various types of users regardless of their profiles. If one wants to allot any extra permissions to one of the users. It has two options:
- One can make changes in the profile of that user, but this is unsuccessful because it’s not necessary that the same profile is allocated to the only single user. That profile could have multiple users who might get to know everything.
- Another way is to create a permission set with those extra permissions and can assign this permission set to a particular user by navigating to User detail page. In this way, one doesn’t have to worry about other users, as only one specific user is getting those extra permissions.
Fig 2. Profiles Vs Permission SetsRoles in Salesforce:Roles are characterized in order to expand the data visibility a specific user has. The data visibility can be increased using sharing rules or by building role hierarchy. Role hierarchy allows the user sitting at the higher level have access to records owned by users having role lower in the hierarchy. It is not necessary that a user should have a role.
- You do not need to define roles for every user:
Fig 3. Roles Hierarchy Equal AccessHowever, if you do not want the managers to have the right to access to any team other than their own team, you need to set it up like this:
Fig 4. Role Hierarchy Having Unique Access2. Roles Hierarchy is the part of the Sharing Rules: Keep in mind while assigning Roles, when selecting Organization-Wide Defaults for sharing rules,” Private actually means anyone above me in the hierarchy can see my stuff.”
- Any Client who wants access of entire database should be assigned the highest role in the hierarchy.
- “View All” and “Modify All” permissions in profiles will affect your sharing rules. You must consider profiles permissions when you create a Sharing Rule, be extremely selective about enabling View All and Modify All in the profiles other than System Administrator Profile.Sharing Rules:
Sharing rules extend sharing access to users in public groups, roles or territories. Sharing rules give you additional record access beyond the original OWD.
- You can add sharing rules to share access to specific objects with groups, queues, or roles that do not have access to the existing role hierarchy.
Fig 5. Sharing Rule
Organization wide default sets the default access for objects, for example, OWD set as private would mean that only the owner of the record can access the record. One way to grant additional access to these records to other users is through roles i.e. users higher in role hierarchy would get the access to records owned by users lower in the hierarchy. Another way is by writing sharing rules, wherein we can specify the logic to decide which record should be shared and with what role user. We can specify against custom objects whether the records should be shared using role hierarchy or not but this is default set for standard objects and cannot be changed.
- Role controls the level of record access the user has.
- Helps extend the OWD settings for different objects.
- Sharing rules can be written to share records with particular role and subordinates.
- Defining the role for the user is not mandatory.
For more information, kindly go through the following link:
Difference between the two can be summarized as below:
- Role defines what user can see depending on the hierarchy (Helps in defining data visibility)
- Profile defines what a user can do within the org (Defines various permissions)
- Defining profile for a user is mandatory, the role is not.