You are currently viewing Roles and Profiles in Salesforce

Roles and Profiles in Salesforce

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.

Conclusion

  1. The role determines what users can see depends on the hierarchy. (Help determines data visibility.)
  2. The profile determines what users can do in org (Specifies various permissions)
  3. Defining the profile for a user is necessary,  but the role is not.
Akshay

Akshay Dhiman

Chief Technical Officer (CTO)

“Akshay Dhiman, the CTO of Cloud Analogy, has been a standout and successful Salesforce Platform Developer for years. He has a rich experience in Salesforce Integration, JavaScript, APEX, VisualForce, Force.com Sites, Batch Processing, Lightning, PHP, C++, Java, NodeJs, ReactJs, Angular 8, GraphQL, React Native, Web Technology, and jQuery. Known for his problem-solving and debugging skills, Akshay is an out-of-the-box thinker and his capability to understand the business context and translate it into a working model is par excellence. Akshay would not only translate his thoughts into reality but would also bring in his own perspective that is always a tremendous value add. Akshay has the knack of taking challenges head on, equipped with In-depth industry knowledge, Resourcefulness and uncanny nag to build relationship with anyone in shortest time possible. Not only does he possesses fantastic technical depth and awareness but Akshay also complements them with a profound understanding of business functionalities, tools, and methodologies. He has the rare combination of skills and talent that one looks for in Salesforce – attention to detail and the drive for innovation.”

Leave a Reply