Controlling the access at the object level
Object is like a table that consists of rows and columns consisting of important or sensitive data of business. Obviously, in today's world, data is something very important. That is why companies invest tons in governing their data. Salesforce is the platform that assures clients about their data security and guarantees data quality.
We all agree that data is money, but the catch is how it becomes gold for us when structured and systematic? This happens when the right user is given the privilege to produce the right data. To avoid data loss, security is as paramount as one's life.
Let's start our understanding of Governing and Monitoring Data
Object Level Security provides the simplest way of managing data access; it's about availing users to either create or view or modify or delete any record of an object. In short, maintaining CRUD access on any object is about object-level security. Great definition, though! But how's it done, and who does it enhance security?
How can we manage the basic level of security?
Object access or CRUD access is controlled via the user's Profile, and to open up this access, we need permission sets. Now let's understand what Profile and Permission Set is.
To privilege a user to log in to the sfdc environment, the user must be assigned one profile. Multiple users can have the same Profile, but one user cannot have multiple profiles. Profile is our designation in the organization or the job level. Every Profile has its own privileges given in the salesforce system. The highest level of the Profile is a system administrator who can perform anything in the environment, but you know what! There are some criticalities that even system administrators cannot do. These include managing licenses which your salesforce support team only can do, and extending data storage.
Apart from this, a System administrator can log in with any user without even granting user access permission. It seems pretty cool; yes, a system admin can do many things.
Salesforce has provided some of the other standard profiles too in the SFDC system; each of these profiles is provided with variable object permissions as per their job, like -
Standard User Profile:
This Profile gets read, edit and delete access to most of the standard objects.
Read-Only Profile:
Read-only user has permissions precisely similar to the standard user but limits the access to read-only.
Marketing User Profile:
This Profile permission has a mixture of standard users profiles' permissions with other additional accesses.
Contract Manager Profile:
This Profile permissions also has a mixture of standard users profiles' permissions with other additional accesses.
Solution Manager Profile:
This Profile as well has permissions like standard users profile's permissions with other additional accesses.
System Administrator Profile:
The only profile with the broadest access to configure and customize Salesforce is the System Administrator profile. The System Administrator profile includes two special permissions -"View All Data" and "Modify All Data".
The special information to note about the above standard profiles is that the permissions they have are provided on all the standard objects and are non-editable. Thus if you want to modify them, one can create a copy of their standard Profile and customize it accordingly as per the requirements of the organization.
One visible app must be there in every Profile; otherwise, you won't be able to see the tabs and access them. Basically, all your day to day record creation would be jeopardized if you don't prevail over the app accesses. Also, only providing the app access will not be enough; object access would obviously be required otherwise, the moment the user clicks on the tab, it will hit the Insufficient privilege error.
Talking about object access is always recommended, or you can call it a good admin practice; never ever privilege modify all access to any custom profile you create because these are admin rights and can splendidly affect the security of your system as this is the central part of our topic.
The interesting part of a profile is that you can do more than just control the object access, like what custom UIs or custom visual force pages access can a user have, or which controller class access user can have which is a part of the VF page or LWC page accesses. Besides these page layouts and record type access, everything is controlled from the profile level.
But we have all kinds of job levels in our organization. Someone entrusted and senior must be obviously privileged so let us now learn how one can open up the access.
What are permission sets and permission set groups?
Now guys, we have seen a lot about how many things can be managed from the profile, how things can be restricted at object level, but there should be some provision to open it up after all our organization is a hierarchy. Our top most people in the hierarchy must be privileged with accesses which are forbidden at lower level. We need to make some our omnipotent, to get these magical powers our admin needs to create permission sets. Technically, permission sets provide additional access to a profile user, which his colleagues won't be getting without modifying the profile access and privileging non-required users.
For example, my dear friends, a sales profile consists of both sales representatives and sales manager role users. A sales manager can delete opportunities, but a sales rep cannot be privileged. Then you will need to create a permission set, grant delete access on opportunity object through object settings and assign it to the sales manager role person.
But there is one more surprise lets say if you are tasked to assign multiple permission sets to one user or multiple users, too much manual work, then what one can do-
1. Go to setup and from quick find search box find permission set groups under Manage users
2. Click on new and create one as per your requirement
3. Assign all the multiple permission set by clicking on Permission sets in Group as shown below under Permission sets section
4. Click on Add Permission set button and add as per the task
So did you just see how easily we reduced the manual work of adding multiple permission sets on multiple users and reduced it to permission set groups. From the permission set group itself you can add users by clicking on “Manage Assignment”. So now that we have seen how the permission set is enough to open up the accesses and give some leisure to the strict security controls.
Difference between Profiles and Permission set -
Till now we have discussed the first level of application security, in the upcoming blog we would be covering the field level and record level security, thus ensuring how we can get high level of security with in and out flow of data and database.
