 Hello, hi everyone. I'm Sanjay Gupta. I welcome you on Sanjay Gupta Tech School. So as you can see, this is day 12 of Salesforce learning bootcamp. And in today's session, we are going to discuss about permissions at group. And third, sorry, fourth level of security, which is record level security. And in record level security, we will be discussing about OWD roles, sharing rules and manual sharing. So I hope everybody gone through yesterday's session and you have done the exercise as well. So it was related to a majorly object level security and field level security. And I demoed you like how you can create profile, how you can assign that profile to user. Then we also saw the use of permission set. So permission set group was remaining. So first I will cover that topic and then I will move on to record level security. Okay, so I think there is some issue with video. Let me just check. Okay, so we'll wait for a couple of minutes. Then I will be starting the session. And I think now video will be clear. Okay. Okay, so moving forward, next we have, so you can see this is my introduction. Then virtual learning best practices. So I think now everybody, whoever is following this bootcamp, you are following the steps. And if you have gone through yesterday's session, so I think you have completed the exercise as well. And today's session is like part two of yesterday's session. Okay, so first I will be explaining the topic and we'll do all the demonstration. And in the end of session, I will take questions and we'll give you the answers. And if you still have any question after the session, so you can utilize these channels. And please follow the channel and share information with as many people as you can, because soon I will be explaining end-to-end admin project. Then we'll discuss about flows and then development sessions will be starting. Okay, so moving forward, so we are in week four of this bootcamp. So today I will be completing data security and tomorrow we will see how we can use data loader. So there are two tools. One is data import wizard and one is data loader. So I will be discussing about both. Okay, so let's first understand the use of permission set group. So yesterday I explained you the use of permission set. So whenever we assign any profile to users, so through profile we can restrict what user can access or what user cannot. Then if you want to open up certain permissions, then what you can do, you can just assign that permission to permission set and that permission set can be assigned to particular user. Now, we have one more feature that is known as permission set group. So first understand what permission set group is and then we'll see the demonstration. So basically permission set group bundles different permission sets together based on a persona, right? So if you have a persona, persona means a role, like on which a particular group of users are working in an organization. So if a group of user are sharing similar permissions, so instead of assigning separate permission sets to each user, what you can do, you can create a group of permission sets that is basically known as permission set group and basis on the persona, you can just club the permission sets and create a permission set group. Then a permission set group includes all the permissions available in the permission sets. So for example, if you have created two permission sets, so whatever permissions you have enabled in that permission set, in those permission sets, so all those will be combined and those will be available in the permission set group. So one permission set can be included in more than one permission set groups. So this is also possible. A user can be assigned one or more permission set groups. So this is also possible. And also we can assign permission set and permission set groups together to users, right? So these are some important points that you need to remember while working with permission set and permission set group. And as I told you yesterday, Salesforce already announced like a few permissions will be remaining on profile and lots of permission will be shifting to permission sets and you can use permission set group as well, right? So you need to focus on permission set and permission set group more along with profiles because these are also important. And I interviewed lots of candidate and like as a beginner, people don't know about permission set group, but it is important tool that you need to know as part of your admin profile, right? So, okay, before moving to this part, let me just demo like how this permission set group will be working. So I have placed one example here. So what we need to do, we need to create two permission sets. One is demo one permission set and another one will be demo two permission set, right? Now, in these permission sets, what I need to do, so in demo one permission set, I just need to add it access to account object. So if you remember in yesterday's session, like we created a profile, so let me just show you that as well. So one by one, I'm going to open what we did yesterday and then we'll be creating new permission sets and then permission set group. So I'm going to open the profile that we created yesterday that was demo user and this demo user profile was having object settings. And if I open account, so here you will see like we restricted added and delete permission on account object. So here this profile is having read create permissions only, right? And we enable these permissions through a permission set, right? So now I'm going to open the permission set. So here it is demo permission set. So what I'm going to do, I'm just clicking manage assignment, okay? So no assignment defined. This permission set is not assigned to any user, okay? So just remember the profile. Profile is having view and create access. Profile is not having edit and delete access on account. So now what I'm going to do, I will be creating two new permission sets, right? I will be creating two new permission sets. So my first permission set will be demo one permission set, which will be having only edit access, right? And for industry field, it will be having view as well as edit access, okay? So I'm going to create demo one permission set. So I'm clicking on new demo one permission set and here I'm going to select Salesforce as license. Then I'm clicking on save. So now I'm going to open object settings and I'm going to open accounts, clicking on edit. So focus carefully. I am going to just give edit access. So if you enable edit, so read will be enabled automatically, but I'm not giving delete access. Delete access I will be giving with different permission set. So I will be having two separate permission sets and then those two permission sets, I will be clubbing into a permission set group. And here on industry field, I am giving read as well as edit access, okay? Now I'm saving it. So this way I created first permission set, which is demo one permission set. This you need to create as part of yesterday's exercise. Then like you can log in with your another user and you will be verifying that this permission set will be giving only edit access. But right now I'm not going to do that because I will be testing it through permission set group. Now I'm going to create one more permission set that will be demo two permission set, right? And in demo two permission set, what I'm going to do, I will be opening up delete access, only delete access, right? So let's create one more permission set. So clicking on new, and it will be named as demo two permission set. And here I'm going to use Salesforce as license and clicking on save. So this way my demo one permission set is having edit access and demo two permission set is having delete access, right? So I'm just clicking on objects settings so that I can enable delete access on this permission set. So I'm just editing it. And from here I'm giving delete access. If I enable delete, so edit and read will also be given automatically. So I'm just saving it, right? So demo one is having edit, demo two is having delete as well. So these two permission sets are created, right? Now what we need to do, we need to assign these two permission sets to a group. So here you can see permission set group option is available. So you can search permission and permission set group option will be there. So here you can create new permission set group, okay? So you can label it so demo permission set group, okay? And I'm clicking on save, right? So here you can see we are on permission set group and you can see we have one option that is permission sets. So you need to click on this permission sets and group. So if you click on this option, so you can see what all permission sets are part of this group. So if I click on add, okay, before adding any permission set, I'm going back to the group and I'm going to open this object settings. So we are on permission set group and here you can see for account object, there is no access. Any object permission is not enabled, okay? So I'm going back, clicking on permission sets and group again and now I will be adding permission sets here. So I have demo one permission set, I have demo two permission set and I'm going to add them, okay? So both the permission sets are added. They are part of this permission set group and you can see last modified date. So permission set group I'm going and now if you want to verify whether the permissions which were there in permission sets, whether they came to permission set group or not. So you just need to click on object settings. So what you can do here you can see you have read, edit and delete permission. So earlier you saw like there was no access and still we are on this demo permission set group but as we added permission sets, so these permissions are enabled. If I open this accounts, so here you can see read, edit and delete permissions are available and for industry you will see read and edit access, right? So this way permissions are given now instead of assigning two permission sets, you can assign this permission set group to the user, okay? So what you can do, you can search for the user. So I'm going to assign it to my test user. So if I scroll, so here you can see I have this option permission set group assignment. So you can just click on edit assignment and from here you can assign this permission set group and you can just save it, okay? So here you can see permission set group is assigned and now if you go and test with the test user, so you will see edit and delete options will be available and you will be able to modify and delete account account, okay? So this way you can use this permission set group. So day 12 exercise, number one point is just I demonstrated like how you can create a permission set group and how you can assign that permission set group to user. So basically it saves lots of time. If you have like 10 permission sets, so instead of assigning those 10 permission sets, you can assign one permission set group and those permission sets you can add into permission set groups. So I think it is as simple as that and it is very useful. Now there is one more feature available with permission set group, which is mute permissions and permission set group. So for example, we created two permission sets, permission set one and demo one permission set and demo two permission set, right? Both are part of permission set group. Now through permission set group, you don't want to give delete permission to the users. So instead of removing that permission set from permission set group, you can just mute that delete permission from permission set group itself. So what is mentioned here? It says one can mute some permissions in permission set groups so that they won't be given to the users, right? So you can just mute. Mute means those permissions are part of permission set group, but they are disabled now and user won't be able to access those permissions. Now you might be thinking if we mute any permission in permission set group, whether they will be impacting that individual permission set or not. So answer will be no. If you mute particular permissions in permission set group, then it won't impact individual permission set. They remain intact, right? So if you do any mute for particular permission in permission set group, so your separate permission set will be intact. Why so? Because it may be possible like your individual permission set you have assigned to someone and it is part of permission set group which you assigned to some other user. So that's why if permission set is part of any permission set group and if you do any mute in permission set group so that muting won't be affecting your individual permission set and you can anytime unmute the permissions in permission set group. So permission set you can assign individually and it can be part of any permission set group as well. But if you remove any permission from permission set then it will be affecting the permission set group automatically, right? So I hope this is clear. Now let's see how we can mute the permissions in permission set group. So what you need to do, you need to open the permission set group and here you can see we have one option that is muting permission set in group. So you just need to click on this option. So here right now we don't have any permission that is muted. So if you see this help text, it says only one muting permission set is allowed per group. Added the existing record to modify muted permission in this group. So you can just click on new and this is label and API name, click on save and by clicking on this label, you will be able to open it. And from here you can just go to object settings, then click on accounts. So this type of UI you will see. If I click on edit, so you can see these permissions are enabled through permission set group. And if you want to mute any access, so mute means you just need to enable this. If I enable this access, it means delete permission is muted. So user who is having access to this permission set group or you can say the permission set group is assigned to the users, those users won't be able to delete any record like if they are using this permission set group. So they won't be able to delete any record because we are muting delete permission. So this way with the help of this option, you can mute any given permission through permission set group. It is available with fields as well, like a separate mute button as for read access and separate mute checkboxes available for edit access, right? So this way you can control muting. If you save it, so it will be applied. So here you can see it is applied. Now, if you log in with your test user, so that user will be able to edit the record, but won't be able to delete, okay? So let me just go here and do a refresh. So if I open any account record, so I will be able to edit the record, but I won't be able to delete. And right now I am not able to add it as well. So it is due to caching. Yeah, so now you can see pencils are available and industry field is available. If I click on any pencil and if I change something, I will be able to change. Okay, active is required. So we need to populate some value and we can save it. But if you go here, so you can see here, delete button is not available. So if delete button is missing, it means you won't be able to delete this record. So we just muted delete permission. That's why delete option is not available. If you go again, add it and unmute this permission. So it means you will be able to delete account records. And if I muted this permission, so it is muting in permission set group only, your individual permission set will still be having that delete checkbox checked. So if you want to make sure you can go to permission set. So let me open permission sets. And if I open demo to permission set, so I'm going to open demo to permission set and I will be visiting object settings. And I'm going to open accounts. And here you can see delete permission as is, right? So this way, if you mute any permission, so that will be impacting your permission set group, not individual permission sets, right? So this was about permission set. Now let's understand record level security. So I think everybody who followed yesterday's video and session and today's beginning part. So I think you are good with object level security and field level security. And along with that, you understood the use of profile permission set and permission set groups, right? So I can see a few questions are available here. So I can just quickly wrap these. So is it necessary to have permission sets for each user? So no, it is not necessary. If you want to open up any permission, then it will be necessary. Swapnel is asking what session activation required checkbox? Yeah, so this I also never used. So I will research on that and we'll let you know. So in general use, you won't be using this checkbox, right? But I will figure it out and you will get this answer in the live session Q&A document. And for your information, that document I updated. So I added few questions along with answers. So you can just check. Munir is asking muting won't change access if user also has permission set, right? Yes. So if you have permission set assigned and that permission set is part of that permission set group, where you muted. So in that case, like you are muting to permission set group, but individual permission set is assigned. So it means user will be able to access. Difference between edit and modify all. So edit will give you edit permission. Modify all will give you added access for all the records, even if you don't have access to records. It means it will give you access to records as well. So today I will be explaining record level security, then you will be able to understand view all and modify all. So yeah, if you enable edit, so modify all will be enabled automatically. It is like by default, you cannot control. Suraj is asking we are giving access through profile then why to use permission set. So Suraj just go through yesterday's session recording. I explained this in detail. Okay, so now jumping to record level security. So first we need to understand what record level security is. So we have three entities in Salesforce which are important as part of data. First is object where we create all the fields and in the fields we provide some information and then a record is created. So first important part is object. Second important part is field and object and fields you can control with the help of profiles and permission sets, right? Now, if you want to manage like whether user can access particular records or not. So that you can do under record level security. So here we have a few points that we need to understand. So you can restrict access to records for users even if user has object level permission. So what does it mean? If you have object access, still there may be possibilities you won't be able to access particular records, right? So that is known as record level security. So for example, a user can view his own records but not others and this happens as well. If you log in in any system, so you have the privilege to access your own records but you cannot access other records even if database is same. So that we can do in Salesforce org as well. So right now we are having two users. One is having system admin profile and one is having demo profile that we created yesterday, right? So system admin profile has spatial privilege which can access anything without any problem but other profile users won't be able to access everything. We just need to make sure like we share things properly and we saw that through profiles and permission sets like if you want to share object and field permission so you can use profile and permission sets but you can manage record level access in following ways. So we have four options. First is organization wide defaults. Second is role hierarchies, third is sharing rule and fourth one is manual sharing. So if we talk about object and fields, so in case of object and field, if you want to restrict, if you want to restrict object and field access so we can remove access from profile, right? And if you want to open up access, if you want to give the permissions, so we use permission sets, right? So profile is restricting and permission set is opening up. So this happens with object and field. Now in record what happens? Let's understand with this diagram. So if you want to restrict record access, restrict means the logged in user will be able to access only those records which are created by that user, not by the other users, right? So if you want to restrict record access, so you need to apply organization wide defaults, right? So first of all, I'm going to explain you how we can restrict record access. Then if you want to open up, if you want to share the records, so we have three options. First is role hierarchy, second is sharing rule and third one is manual sharing. So we will discuss each and every step in detail, right? So first I will show you how we can restrict record access and then I will be showing you how we can open up the permissions, right? Now if I move forward, so first let's understand what OWD is, then I will be restricting record access and then I will show you how we can open up. So basically OWD, organization wide defaults, specifies the default level of access to records. Org wide sharing setting, lock down the data to the most restrictive level. So we have three access levels, private, public read only and public read write. So for most of the objects, a by default setting is public read write. It means as a user, you can access your own records as well as you can access other user records as well, right? If you want to restrict access, so you can just select private. If you select private, it means you will be able to access only those records which are created by you, not by other users. And if we are using any sharing thing like role hierarchy, sharing rule or manual sharing, then whatever records is being shared with you, you will be able to access those records, right? So last point says you can use other record level security and sharing tools to open up the sharing of records. So to lock down record access, we use OWD and to open up, we use roles, we use sharing rule and we use manual sharing, right? So now let's jump to the org again and here I'm going to show you. So you can see I am using two browsers, two browser window, one is normal where I have logged in as my system admin user, right? And in cognitive window, I am logged in as test user and test user is having profile as a demo user, okay? So these two interfaces are available. Now, if I click here on accounts and go to all accounts, so here you can see I can access 15 account records and I will be refreshing this page again and again and whenever I refresh, so it will automatically show recently viewed because it is pinned. So what I'm going to do, I'm just pinning this list view. So you can see all account is pinned. Pinned means by default, whenever you refresh the page, this list view will be opened, right? And in this list view, you can see total 15 records are available and here you can see owner. So for most of the record, owner is S, GUPT. This is system admin user and for these two, you can see test user, T user, T user, right? So these two records are created by test user and this one is created by auto process and rest of the records are created by S Gupta which is system admin. So right now in this window, I am logged in as test user but still I can see the records which are owned by another user that is Sanjay, right? Now if I come to system admin and click on accounts, so here also you will see, so I'm just pinning it so that it will be available automatically if I refresh. So here also I can see 15 records but whenever I will be restricting record access, still I will be able to see all these records with system admin profile user because system admin has spatial privilege, system admin profile can access anything irrespective to the security, right? So now how we can restrict record access? So from here, you need to search for sharing settings. If you go to setup, search for sharing settings so this option will be available and here you can see we have OWD, organization wide defaults and list of objects available. Then we have two access, default internal access and default external access. So right now we will be focusing on default internal access. So default internal access means the users which are created in your org, they will be affected by these settings and I don't know if you have heard about communities or experience site that we can create in Salesforce. So this is a cloud which is known as experience cloud. So in Salesforce you can create a website kind of thing that is known as experience site and if you want to control access for that experience site then that is known as default external access. So right now you can just ignore it whenever you will be learning about experience site you can just recall like how you can control access and we will be focusing on the default internal access as of now. So here list of objects are available. So at top you can see all standard objects are listed. If I scroll to bottom, so in our org we created few custom objects as well. So we have class, instructor, STD class and student. So these are custom objects. All the custom objects will be available at bottom. Okay and they are sorted alphabetically both standard and custom. Now for few you can see OWD status private for few public read only, for few public read write, for few controlled by parent. So wherever it is controlled by parent so it means object is sharing master detail relationship. So if you remember in master detail relationship I told you the sharing of master object will be applied to child, right? So that is basically happened through this. So now what I'm going to do from here like for account and contract object I'm going to select access as private. So if you select private, so it will ask this pop up. So you can just click on okay, then again click on okay and then click on okay. You can read the messages and then click on okay, right? So this is now private and I'm just clicking on save. Okay, so you can see it is showing a warning one or more sharing operations has been initiated. See below for additional details certain operations may not be available. So right now it is still public read write but in few minutes or few seconds it will be updated. So what you can do just refresh your page and wait for the changes applied. So it will be soon converted into private. So right now still it is public read write but if you wait for a couple of minutes and then if you refresh it will be converted into private. Before like if we are waiting for a couple of minutes so you can see here we have one more option that is grant access using hierarchies. So this means it is for role hierarchy. So after this explanation I will be explaining you about role hierarchy. So if you want to give access to role hierarchy then this checkbox will be enabled. So for standard it will be enabled by default. Means if you set up roles then for these objects role hierarchy will be having access. Like if you apply role hierarchy so your record will be shared automatically and for custom you can control. So let me just click on edit so that I can show you which we can modify and which we cannot. So you can see these are disabled we cannot modify. And here you can see three we can modify and the junction object which we created so that will be having master detail relationship so that will be controlled by parents so that we cannot control here but these three you can control whether they will be part of role hierarchy or not. So this is another interview question in many of the interview interviewer can ask like what is the use of grant access using hierarchies. So you can say for standard object it will be enabled by default it means if we apply role hierarchy so record will be shared basis on the role hierarchy but for custom object we can control whether we want our custom object to be a part of role hierarchy or not. Right so now I'm just clicking on cancel and here you can see for account and contract it is converted into private. Right so right now our OWD is set to private. Okay now what we need to do first I'm going to refresh this system admin page and I already pinned this list view so if I refresh so recently viewed the list view won't be available all accounts will be available. So you can see you can view all 15 accounts because here in this window we are logged in as system admin user. If I go to different window which is incognito window if I refresh here here also I already pinned so you will see all accounts when I refresh. So I'm just refreshing the page and you can see all accounts list view is available and I can see only two records which are owned by a test user. Other 13 records are not accessible. So this means we have successfully applied OWD. So now record level access is restricted so a user will only be able to access only those records which are accessible or which are created by this user. Okay and in your case if you have not created records so just create a record first and then try to test it so that you can see the differences. Right and we just applied OWD for account objects which will go for account. If you want to enable for other objects you need to do that for other objects and then you can just test it. Okay so this way I hope you understood like how we can restrict record access. Now we need to understand how we can open up sharing. So if OWD is applied it means test user won't be able to access the records of another user which is system admin. But my requirement is I want to share the records which are owned by system admin with test user. So it means I want to open up sharing. So we have first option which is known as role hierarchy. So it gives access for users higher in the hierarchy. That user can access all records owned by the user below them in the hierarchy. So each role in the hierarchy should represent a level of data access that a user or group of user needs. So basically if we take an example like if you're working in an organization and you are reporting to someone someone is your manager and whatever records you are creating in the org so that information will be automatically shared with your manager. So that hierarchy is basically known as role hierarchy. It means the people who are working above to your hierarchy they automatically will be having access to your records. This is basically known as role hierarchy. So now we need to understand how we can configure it. So to configure role hierarchy you just need to search for roles and here we have roles option available. Okay, just click on setup roles and here you will see two buttons. Collapse all and expand all. So I'm clicking on expand all and at top you will see the organization name with which you created your first account, first record like your user record and here we can see various roles are available. So first of all we have CEO and under CEO we have CFO, CEO, SVP. Under SVP we have different roles. So this is standard role hierarchy which is provided by Salesforce. If you think like you are working on a project and this role hierarchy is not as per the requirement of business. So anytime you can add it, delete a particular role if you want to add more roles you can see this add role option is available. So let's say you have a managing director role as well which is equal to CEO. So here you can add one more role which will be in same level of CEO. If you have any role which is under CEO so you can just click here and you can add role. If you want to add role under CFO then you can see the hierarchy, right? So this way this role hierarchy is available here and through this role hierarchy you can just assign the users and automatically record sharing will happen, right? So now we have two users. One is system admin which is Sanjay and second is test user. Sanjay can access all the records because profile is system admin and test user is not able to access the records which are owned by system admin. So what I'm going to do I'm going to make test user as CEO because it will be on top of that admin user. So just focus on this. I'm just going to assign my test user as CEO. So you just need to click on assign and from here you can just select all users. So all user list will be available here and I'm clicking test user and adding it. So my test user will be assigned to the CEO role and I'm clicking on save. And also remember for one role you can assign multiple users as well. So test user is assigned as CEO. Now that system admin user I am assigning as CFO which is below two CEO. It means the records which are owned by system admin profile user they will be shared with CEO because CEO is on top of CFO. So here I'm clicking on assign and I am assigning Sanjay Gupta user to CFO role and clicking on save. So this way I just set up role hierarchy. So I just assigned the users and sharing will be happening automatically. So if I go to this window which is on system admin user, if I refresh so you will see all 15 records are still accessible. If I go to incognito window and if I refresh you will see records which are owned by test user as well as records which are owned by admin. But auto process record like earlier we were having 15 records one is created by auto process. So this we didn't share. We just shared the record of Sanjay with test user through role hierarchy. So you can see total 14 records are accessible now. This way if you configure role hierarchy so the records of subordinates will be shared with the user which is above in the hierarchy. Right? So this way if you assign particular users in this role hierarchy so automatically record sharing will happen, right? So this was one way to open up record access, right? But it is like vertical sharing. If you are reporting to someone then only that person can access the records. Now we have one more scenario. Let's say we have two teams in an organization. So one team is having a manager to that manager let's say 10 people are reporting so all those 10 people records will be accessible by the manager. So manager one can access all 10 people record. Now we have team two which is controlled by manager two. Manager two can access the records of his subordinates. Now from team one if anyone want to share the records with manager two who is managing any other team so there we don't have any role hierarchy. So if you want to accomplish this type of sharing like you want to share your records with particular people or particular group of people so we have another sharing thing that is known as sharing rule. So these are exceptions to org-wide defaults. Through sharing rules you can share records to a group of users so that they can get access to records they don't own or can't manually see. Right so if you don't want to go through role hierarchy or like you want to go beyond the role hierarchy so we have another thing that is sharing rule. Now before implementing sharing rule and testing that what you need to do because we have limitation of two users only in this org we can create two users and both the users are already aligned with this role hierarchy. Okay now if you want to test sharing rule so you need to de-assign or you need to unassign those users from these roles. So what I'm going to do I'm clicking on assign and I'm going to remove this user and clicking on save. Okay then I'm going to click on assign for CFO and I'm removing this user and save. So this way I unassigned both the users from role hierarchy. Now if I go here and refresh you will see test user will be able to access only two records which are owned by that user. The records which are owned by a system admin are gone as we unassigned users from role hierarchy. So this way you need to make sure you just need to assign users to role hierarchy then unassigned then again test. So I just created exercise for you so that you can do this. So whenever you perform role hierarchy then test whenever you remove users from role hierarchy then again test. So everything is mentioned here so you just need to do these step by step. Now what we need to do we need to focus on this sharing rule. So now users are unassigned from roles so we can create sharing rules. To create sharing rules again you need to search for sharing settings right. So this I already explained. So we are going to create sharing rules. So if you scroll this OWD you can see this is OWD page and if you scroll down so you will see sharing rule options for each object and if you go at the bottom so you will see custom objects as well as class instructor and student. So right now what I need to do I need to create a sharing rule for account right. And for that I just need to click on new. Here I have two options. One I can create based on owner like I can share records based on owner and another one is based on criteria. So first of all I'm going to show you how we can share records based on owner. So if we see like if you want to share records basis on owner so what will happen? The records which are owned by a particular user all those records will be shared by another users right. Now we have step number three so it says select which records to be shared. So we have three options public group role roles and subordinates. So like initially in one of the session we discussed about public group but we have not created but here we don't have any option. We have three options right. So from these options if you have created a public group where you have group of users so you can select that. Otherwise we have only one option that is all internal user. So it means all internal user records will be shared. Then we have with whom you want to share right. So here also you will find all internal user. It means the records of all users will be shared with all other users. It means this. If you want to create a public group so that is also possible. So let's create a public group first. So you can search for public group and here I'm going to create new group and labeling it as demo public group and here I just need to add users. So I'm adding these two users. As part of this group and I'm saving it. So you can what you can do you can add one public group into another public group. You can assign roles as well. So if you assign role, so whatever users are tagged with that role they will be part of this public group. Now after creation of this public group if you search for sharing settings and if you scroll down so here you can see we have account sharing rule. Again I'm clicking on new. Now I'm writing account sharing rule as label. Rule name is ACC underscore sharing underscore rule. A rule type is based on record owner. Now public group so you will see our demo public group. So this way if you have two public groups so from one public group whatever members are there if you want to share their records with another public group. So from here you can select another public group. Let's say I'm selecting all internal users. So right now we have limitation like we have only two users and both the users are part of this internal user public group as well as demo public group. So it means both users record will be shared with each other. In real time projects you will be having lots of users and then it will make more sense. But I hope you understood this is from and this is to. Step three says whose records you want to share and step four says with whom you want to share. And with account we have these access levels like if you are opening up access. So by default it is private. So what you want to do you want to open up access as read only or read write. Okay so it depends on you if you give read only access so only like user will be able to view the records and opportunity and cases are related to account. So you can select these options from here and whatever option you select the records which you are sharing for those records these permissions will be applied. And for records which are already owned by that user different permissions will be applied as per their accessibility. Okay so I'm just clicking on save. So this way here you will see account sharing rule is created and once it is created you will be receiving an email as well. So the system admin user will be creating an email like it is created. And if I go here and refresh so there will be no change system admin is still able to access all 15 records. If I go here and refresh so you will see more records. So you can see 14 records are shared now. So we removed users from role hierarchy. Now role hierarchy is not working. What is working are sharing rule and the sharing rule is owner-based. Owners all record are sharing. So system admins all records are sharing. Now you might be thinking what if I don't want to share all the records of particular user. I want to share some limited records, right? So for that purpose you have another sharing that is criteria-based sharing, okay? So to create that I'm what I'm going to do I'm deleting this. So remember these steps how I'm demonstrating because if you do practice so you need to do these as well because if you create everything you won't be figuring out like which part is opening up the access. So if you create roles so test and remove users from role if you create owner-based sharing so test and then delete it then you can create criteria-based sharing. So again I'm creating it this time I'm going to select based on criteria. So now we need to apply the condition. So let's say I'm applying condition as active equals yes. So only those account records will be shared where active field value is yes. No matter who is the owner of that record, right? So if you have 10 users and if each user is having certain account records where active is yes all those users record will be shared with someone and with whom we want to share so here you can see. So this is basis on criteria earlier it was basis on owner but now we selected based on criteria so we need to select criteria. You can select multiple conditions as well then from here I'm selecting demo public group, okay? And these three permissions are same and if I go here and refresh so as I deleted that sharing rule so you can see only two records are shared. Now I'm going to save it. So I just need to click on save button and it will be created. Okay, it is being refreshed. So whenever you create new sharing rule so everything is recalculated or re-initiated so a sharing rule operation is currently in progress the initiating user will receive an email with each operation finishes, right? So if I refresh it a couple of times so you will see changes are applied and this new sharing rule is created. Now if I go here and refresh the page so I won't see all 14 records I will see few so you can see total 12 records are available two are owned by test user and 10 are owned by system admin not 14, 12 only because on two records active field is having value as no. Okay, if you want to change condition you can do that as well. So right now you can see we have this so if I click on added and if you want to change conditions from here so let's say I want to select type as customer channel which is populated on four records only so what I'm going to do from here I am selecting type equals and I'm removing this value and I will be selecting customer channel, right? So I did this change now I'm just clicking on save, clicking on okay, okay so this is updated now if I refresh the page so you will see different set of records so two records are owned by test user and remaining four are shared through other users wherever type is customer channel so right now we have only six records so this was related to sharing rules now we have last sharing that is known as manual sharing so in manual sharing if you want to share one particular record if you want to share specific records with specific user then you can do manual sharing so it allows owners of particular record to share them with another users manual sharing is not automated like org-wide defaults, roll hierarchy or sharing rule it can be useful in some situation where you manually want to share a record with another user, right? So for this you don't need to remove the last sharing rule we created because I will be just sharing one record so here you can see total six records are accessible okay now I will be sharing one record where type is other than customer channel so that one record will be shared and total number of records will be seven here so what I need to do I'm going here and I'm opening this one Burlington Textile and from here we have this sharing button so if you click on the sharing button so it will give you option to select the user so from here I'm going to select test user with whom I want to share if you want to share with more than one user you can select them we have options like public group, roll, roll and subordinate so accordingly you can just select the entity and whatever users are associated with that entity with those users your record will be shared and account, case and opportunity access you can set and just click on save, right? so record is saved if you again click on the sharing button so here you can see like this record is shared with two users if you click on edit so one is the owner and another one with whom this record is shared if you want to revoke access you can just remove like it is similar like we share Google Sheet or Docs now if I come here and refresh the page so you will see total seven records so here you can see one more record is shared which is having type as customer direct and four are customer channel and two are owned by test user so this way if I go back so now I hope you will be able to understand this diagram properly so if you want to restrict record access you need to apply OWD first then for vertical sharing you use roll hierarchy for horizontal sharing with any group, roll or roll hierarchy like roles and subordinates you use sharing rules and if you want to share specific records with specific group, role or user you can use manual sharing, right? so it depends on the business requirement which way to go you don't need to decide yourself it will be decided by the architect of the project in discussion with the client and as a developer you will be like configuring these things and this is important for QA, BA, admin, developer, architect project manager, everyone should know the data model like this security model which is layered so object security, field security and record security you need to understand like how we can perform so again in interview like there will be questions like object and field level security through which we control so object and field access will be controlled by profile and permission sets only and if we talk about record access so those will be controlled by OWD roles sharing rule and manual sharing you cannot control record access with profiles and permission set only we have two options, view all and modify all so if you have applied OWD as private if you have applied OWD as private like you can access records of record which are owned by you only but on your profile if view all or modify all are checked then irrespective of OWD private you will be able to access all the records so those are exception to record level security so on profile we have only two check boxes view all and modify all that will bypass your record level security through profile or permission set right so this is all about today's session like yesterday and today both the sessions are related to data security so if you have not gone through yesterday's session go through and I just created exercise sheet for you so you can see day 11 we have object level security field level security profile and permission set and in today's session you got to know permission set group then you can apply OWD role hierarchy so everything is listed here because I demoed but if you want to test your knowledge you can go through the steps and then assign things then test then unassigned then again test whether you are seeing any changes or not and wherever you get stuck so this recording will be available you can just go through and test whatever way I did and accordingly you will be able to and in our end to end project everything will be covered so there you will get to know like how we will be creating profiles and permission sets as per the business requirements so that I will be sharing with you next to next week right so in these weeks we are just getting familiar with the topic and then whenever we will be implementing the whole project so you will be understanding the requirement of all the entities which are available in Salesforce okay so those who understood everything and they are good with exercise questions as well so they can leave and now I'm going to pick more questions and we'll try to answer those so I think I answered this Sura's question I answered then next is if we have modified all permission and we have to block delete permission how we can do it if we have modified all permission then we have to block delete I didn't get your question like Nimish can you please explain your question a little bit more because you are saying if we have modified all permission and we have to block delete so you can just uncheck delete permission you can give modify all permission and if it is checked automatically so you cannot control them right because it is happening through system then what is the benefit of using mute instead of mute you don't give permission Srikanth like I already explained you muting means those permissions are part of permissions at group but due to some reason for some time duration you just want to mute that permission you don't want to give that specific permission then that option is available so you can just utilize this just marry there is lots of stuff that's why like on daily basis we are discussing and I think on daily basis if you do a little bit then it makes sense instead of doing lots of thing in one day so do exercise day by day and I think like this week and last week I took only three sessions every week so you have enough time to practice on weekends as well so if you're doing job and still learning Salesforce so you can just manage your day because I saw like many people requesting like we are not able to follow proper schedule to learn Salesforce so this bootcamp I hope is helping you to maintain our schedule then next question is quick actions and object specific actions are also managed by object security no these are additional features they will be controlled through page layouts if you place them on page layout then only a user will be able to access but through these quick actions if you are creating new records then those things will be controlled by the security then Tushar is asking in real life if we need to find out why a certain user is seeing record what would be the best way to check since there is so many things going on so very good question Tushar so first of all you need to verify OWD like for that particular object what is OWD set once you identify the OWD then you have three options role hierarchy, manual sharing and sharing rule so one by one you can just open those things and you need to verify right and if you go to user record and if you assign that user with particular role so through user record also you can identify with which role it is associated and sharing rules you can see under the sharing settings and for manual sharing you just need to open that particular record and just click on sharing button there you can see like with which user this record is shared so three things at least you need to check one by one Divya is saying can you please explain this security in pictorial representation so I think for record access I showed in pictorial way and this you just need to imagine and I showed each and every demo as well so like beyond that it will take lots of time to create some pictorial representation because it is very simple we have two users one is having access to the records which are owned by that user if that user want to access records of another user then we just use roles sharing rule and manual sharing so role will give access to the superiors sharing rule will give access to anyone with whom you want to share and manual sharing like you just share one record with user or group of user next Amar is asking can we share more than one record to the particular user with the help of manual sharing at one go no, because manual sharing means you are opening one record then you are sharing it then you will open another record then you need to give Praveen is asking sir if we give two sharing rules one is based on owner another one is criteria based which will perform both will perform and all the records will be shared suppose the test user won't want to share his records to S.Coupta how to set up S.Coupta is basically having profile as system admin and system admin has a system permission to view all data that's why you cannot control so if you want to control you just need to change the profile of that user so system admin profile is exception for all through system admin you can do anything so I think first I already answered Tushar's question like step by step you just need to verify though it is complex but we don't have any option because in a complex project if everything is applied so basically in complex project we maintain a Excel sheet that Excel sheet will be having all the object permission field permission and record permission so through that you will be able to identify like for which object what permissions is given what profiles are there what permission sets are there what is role hierarchy how many sharing rules are there so we need to do lots of documentation as well okay so moving to next question can you share records with more than one group yes we can but for that you need to create separate sharing rules only one record can share at a time by a manual sharing yes so no explain very very nice sir understand everything okay thank you Sonali please make sessions on Salesforce Classic Jyoti Salesforce Classic is outdated so on my channel you will find 30 35 videos but I won't prefer to watch those because it is outdated if OWD Nilesh thank you for thumbs up Praveen is asking if OWD is public read shall we perform sharing rules to other users so if OWD is public read shall we perform sharing rule to other users I didn't get your question Praveen can you please explain more Sonali is sir internship is available by you not now I am planning for that so maybe soon I will give that option Jyoti is asking please try to make session on Salesforce no I already answered this how do you troubleshoot and resolve issues related to permission sets and Salesforce so this can be done through testing only so in testing you will realize issues and basis on that you will be like configuring your permission sets that's why in projects we have separate developers and QAs Mary thank you for appreciating my efforts next is what is delegated users please give one example so Shubham delegated user means like if you want to delegate your rights to another user so that on your behalf any other user can work so that user will be having access to the permissions those you are having so that is basically delegated user so if you go to user records so there you will find a field where you can pop up delegated user Jyoti I already told you I won't be creating classic videos because it is outdated Srikanth is asking what is the benefit to use mute instead of this we can remove permission so Srikanth question is good but we cannot remove permissions from permission set group if you want to remove so you will be removing it through permission set and for example if your permission set individually is assigned to some user so it is impossible for you to remove that permission because in that case permission set is part of two things it is assigned individually and it is part of permission set group as well so instead of removing that permission from permission set you can mute that through permission set group that's why this feature is available Shreesha I think we already discussed through OWD organization by default we can hide records from users if you set it private for a particular object Mangesh is asking campaign object has full access as OWD can you tell okay let me just check for campaign object because so public full access okay let's see what other options are there yeah this I just need to check because I never gone through with this this is a good question so Mangesh I will answer this question and this questions answer you will find in that document Digambar is asking about restriction rule so yeah this also I need to explain so next week I will be covering all the remaining topics so this restriction rule I will be covering next week so I'm just adding it into the sheet so that I remember okay so it is added Vinayak is asking supposing all three users as Gupta A and B how to set up A user records cannot show to B user and we need to log in as A user and set it or any other way so I think if you apply OWD then users will be having access to their own records so next is Saptya is asking what about APIC sharing when we should go for APIC sharing can you please elaborate it yes if you want to do sharing through code so there may be some requirements like you are implementing custom solution and in that custom solution there are scenarios like you just need to share records with the user so in that case you can apply sharing through APICs as well so those who don't know we can share records through APICs sharing as well through APICs programming Nimesh is asking can we create sharing rule for single user no you can create like you can create a public group where you can just add one user in that way you can create sharing rule for single user Digambar public group we use as a group of user Q is basically we use in service cloud so right now I won't be able to differentiate because Q is having separate features and that we need to discuss separately so this is my first lecture and it is really helpful very good initiative thank you Nitin and you can find session tracker link in the description of this video where you can see all past recordings as well thank you Srisha yeah my idea was like launching this bootcamp was same like many folks are like getting confusion like whether to start Salesforce or not so I think with this bootcamp people are learning things and they can decide their future path whether to go with Salesforce ecosystem or not because once you get to know things in detail then only you can decide like whether you are able to understand or not and all the sessions are available free of course so you don't need to pay anything so freely with free mind you can just learn things on YouTube thank you Rekha for appreciating Vinayak is asking please make one video about sales cloud, service cloud, marketing cloud yeah so I have planned those things as well but right now my focus is this admin and development bootcamp and soon you will be having those videos as well yes Sonali you can ask doubts there like lots of people are part of that telegram group and they will answer your question assignment rule Vinayak it is also part of sales and service cloud so I won't be covering it here Gayathri yes we are muting permissions in permission set group Sonali is asking if a record has owner as a queue can we also restrict to yes so if you are the owner if your user is the owner then only you will be able to access thank you Mangesh for appreciating thank you Pallavi okay so if anyone is having any more questions so please ask and those who are appreciating my efforts thank you and if you want to appreciate efforts like you can see on the slide if you want to buy a coffee for me so you can use super thanks super sticker and super chat these options are available on YouTube so anytime if you see like you want to appreciate my effort and if you want to buy a coffee for me so I won't mind so I think there is no question now so I'm just wrapping the session and tomorrow I will be discussing about data import wizard and data loader that is also important and I will recommend join that session if you do miss then you can just go through the recording and I will be giving you exercise on that as well yes Anna these object level security free level security profile permission sets permission set group OWD everything we will be covering in the admin project as well Sanket we I don't think we will be getting pop up and frankly speaking I never use this log in our setting so I think you will be logged out automatically there won't be any pop up because if time limit is not permitting you so you will be automatically logged out from your session thank you Swapnil okay thank you everyone so we'll see you tomorrow with new topic and new exercise thank you everyone