Security and sharing play an important role in an organization. The information has to be shared with authorized users without violating security concerns. All the users in an organization don’t need to access all the information, a user should get access to only the information that is relevant to him. In Salesforce, this can be achieved through Roles, Profiles, Permission sets, and organization-wide sharing defaults and sharing rules.
What are Profiles, Permission Sets, and Roles?
A profile in Salesforce is a group of settings and permissions that determine how users access records. Utilizing profiles, we can set Field Level Security for Objects, User permissions, fields, tab settings, and so on.
Profiles in Salesforce control the following things.
Page Layout – Which Page layout users can view?
Field-level security – Using field-level security, we can prevent users from creating, reading, editing and deleting fields.
Custom Applications – Standard and custom applications that users can view.
Tab – Tab that users can see.
Recordings type – Which record types are available for users?
Input – Login IP and Salesforce login Hours deadlines can be set.
Types of Profiles in Salesforce
Standard Profile – Salesforce’s default profile is created by default with Force.com and cannot be renamed or deleted.
The most common standard profiles used in SFDC are:
- System Administrator – The system administrator is a superuser (special user account for system administrators who can customize every application in an organization.
- Standard users – Standard users can view, edit, and delete their own records.
- Solution Manager – Solution Manager can adjust standard user permissions, published solutions and solutions categories.
- Marketing users – Marketing users can import organizational leads and have all standard user permissions
- Contract Manager – The contract manager can edit, approve, activate, and delete contacts and also has all standard user permissions.
- Custom profiles – Custom Profiles in Salesforce are defined by the user. These profiles can be deleted and edited.
Permission Sets in Salesforce
Permission Sets in Salesforce are a part of Salesforce Security where users can access Settings and Permissions to various tools and functions. The settings and permissions in permission sets are also found in profiles, but permission sets extend users’ functional access without changing their profiles.
For example, to give users access to a custom object, you need to create a permission set, enable the required permissions for the object, and assign the permission set to the users. You never have to change profiles or create a profile for a single-use case. While users can have only one profile but they can have multiple permission sets.
Permission sets involve settings for:
- Assigned apps
- Object settings that include Tab Settings, object permissions, Field Permissions
- Apex class access
- Visualforce page access
- System permissions
Limitations of permission sets in salesforce
- Permission sets can’t be assigned to custom objects in a master-detail relationship.
- You can’t change the user license in a cloned permission set.
- Regardless of permission settings, Triggers always fire on trigger events (such as insert or update).
Roles in Salesforce
The role represents the hierarchical model of an organization. Roles give permissions to perform tasks to administrators and users. The same role can be shared by multiple users and they may or may not have the same permissions. A Role can be assigned to the user at any point in time.
Role hierarchies in Salesforce are sharing settings at the application level. Role hierarchies and sharing settings in Salesforce determines the level of visibility that users and its subordinates to access object records. A role hierarchy controls the level of visibility that users have to an organization data. By defining role hierarchies we can share access to records.
- The role determines what users can see depends on the hierarchy. (Help determines data visibility.)
- The profile determines what users can do in org (Specifies various permissions)
- Defining the profile for a user is necessary, but the role is not.
Chief Technical Officer (CTO)