 Okay, so we are going live now. Hello everyone, I'm Sanjay Gupta. I welcome you on Sanjay Gupta Tech School. So as you already know, we are doing mock interviews. And for the same, I have Pulva with me. So welcome Pulva on the channel. Thank you. Okay, so in continuation to the mock interviews for admin related stuff. So we did one session yesterday and today also we are having one session. So again, I will be throwing some questions to Pulva and Pulva will be answering them. So she will be defining the definitions and will be relating the answers with real life examples. So that in interview, if you encounter any question related to that, so you will get to know how you can answer that. And feel free to ask any kind of question related to the topics which we are discussing, right? So I will be picking some of the questions from the chat. Okay, so let's start with the question answers round. So we did lots of discussion related to basic configuration yesterday. So I will be picking two, three questions from basic configuration and then I will move on to the sharing and security model. Right? So before starting sharing and security questions, I just want to know what record type is and how a fresher can explain the requirement of record type in Salesforce. Right. So I think there is always confusion while explaining the page layout and the record types to people. So in order to understand its simpler way is if you have to assign. So first I will explain a little bit about page layout and what exactly page layout is because record type is connected with page layout. So whatever you see on any of the object where you see the fields, the backend system, how to rearrange the fields, how to create sections, all these you can do on the page layout. Now, if you want to assign particular page layout through two different profiles, then you need something. So that's where the record types comes into the picture. For example, let's try to understand this example. There are separate users who are working in a company and you want your users to access separate fields with some separate pick list values. For example, if the users are in India, they should have access to certain fields and they should have access to certain pick list values in some of the fields. And some of the users are working in outside India. They need access to certain fields. So how you're going to assign that. If you change the page layout, the page layout will be changed for everyone or it will be changed for the set of profiles you are assigning that page layout to. That's where the record types comes into the picture. You can create separate record types and based on that, you can assign some specific fields from that page layout with the help of record type. You will be able to give access to those users only to those specific fields. So just to give visibility of the page to certain users, you use record types. Yeah, perfectly answered. So if I summarize it, so if you want to have different fields on different layouts, because by default, whenever we try to create new record. So one page layout is attached default. Right now if you want to have few fields on one page, few fields on another page, right? So you will be having two page layouts and to launch those we need record types. So rightly explained. And the second one that you explained is pick list values. So if you want to control pick list values, then you need to use record types for that. Right. And as we are talking about pick list values, I think we can add or throw some lines on sales process also because sales process is something where we rarely talk about this. And if there is any question related to sales process or if somebody has asked question related to if you can change the status or the opportunity stage, how you're going to do that people will get confused. Because in record types, standard pick list values are not available for editing. You cannot change stages. You cannot change lead status. For that you have sales process, lead process on lead and sales process on opportunity and we have support process on cases. So this is how you will manage the pick list visibility of the fields through these processes which you have separately apart from record type. Yeah, so just make sure there are only three pick list values one on opportunity that is stage and on lead and case object it is named as status. So only these three pick list we need to control through for opportunity we have sales process for case we have support process and for lead we have lead process. Rest other pick list you can control with the help of record type. So it was nice explanation. Because this is confusing. So whenever we want, we want to create a record type on opportunity case or lead. So like we need to create these processes. Then only we will be able to create record types. Right. Okay, so moving on to the next question. So we have a feature known as schema builder. So can you throw some light like why schema builder is there? What is the use of that schema builder and can we create some objects or fields from schema builder? Right. So yesterday we discussed about relationship and somebody asked one question that how to identify the relations between the objects, whether these objects have master detail or lookup. So schema builder is just the visualization of the objects where you will be able to see the relations also between the objects. You can create a flow chart amongst all the objects and check the connectivity that what object is related with what standard relationships you can check you can check custom relations also. So with the help of schema builder, it will give you a better visualization of the objects at one page. And you can create objects also through schema builder. Right. We can create object as well as we can create fields also. But one thing you need to notice whenever you create fields from schema builder, so it won't be added to page layout automatically. So if you're creating fields from schema builder, you need to add them manually on the page layout. So like we rarely create objects and fields through schema builder for that we generally use object manager. But for pictorial representation, like which object is connected with which, as Pooja explained, like whether it is master detail relationship or lookup relationship. So for that purpose, you can have that schema builder. So sometimes like if you are a business analyst and you are interacting with the client and you need to just explain the data model. What all objects you have what fields are there on that those particular objects. So what you can do you can create like simple, simple slides. So if you have like 1520 objects, so you can divide them into pieces right as per your processes. And then you can take some screenshots you can put them on your slide deck and you can present those pictorial representation of object relationships to your client. So it will make a good impact. So this way, like if this question will be asked in an interview, so you can just answer in this way, right? So you can just compare schema builder with object manager. Okay, so moving on to the next question, it is related to data. So as we know, like in Salesforce, everything moves around data, right? So if we have data, we will be having processes, right? So suppose I have thousands or millions of records in an Excel sheet and I want to upload those into Salesforce. So what all tools I can use to upload data into Salesforce? Right. So this comes under data management where you can not only upload the data from an Excel to Salesforce. However, you can extract the data from Salesforce and you can also update the existing data and you can also absurd where you can use the combination. You can update the existing data as well as you can upload new data also at the same time. So we have import wizard, which is the inbuilt Salesforce feature. You do not need any third party integration for that. And then we have data import wizard, which is a third party to inbuilt in Salesforce, but you have to download it based on your operating system. If it's a Mac or if it's a Windows, there are instructions provided within Salesforce itself. You will find it and just have to click on it and download it. So two options available to upload the data. If we talk about within Salesforce, otherwise you have workbench and data.com and other tools also available. Where you can run query and play around with the data. So why we have, I get this question from a lot of candidates that why we have two places and there are few mass update features within Salesforce. Also, if you want to update mass owners or if you want to extract the whole data, you have data export schedule import or schedule export feature also in Salesforce. So let's bifurcate this in order to make this simpler. Let's start with data import wizard. So when you are using data import wizard, first of all, there is a limit that you cannot exceed more than I think 50,000 records. If that's the limit, you can upload only custom objects and the in standard objects, you cannot upload opportunities or products. There is limitation. You can only upload campaigns, leads, accounts, contacts through data import wizard. However, through data loader, you have the expansion where you can upload the data to 5 million records and you can you have more features also through data import wizard. You cannot export the data. You have only three operations which you can perform. You can insert the records new ones from your Excel file to Salesforce and you can update the existing records which you already have in Salesforce. If you want to update the records in bulk and you have absurd command where you can put some existing data of your Salesforce into your Excel file and you can add some new records also. So it will perform two operations at the same time. New records will be added as well as existing will be updated. But through data loader, you will get more operations like you can export and export all. Now there was one question which was asked to me during my initial career days that why we have export and export all in data loader. Those who have used data loader, they will know that we have two options for export and export all. So I'll tell you the basic difference between export and export all is that export all will give you the deleted records also exported which are there in recycle bin. However, using the export command you will be able to export only those records which are there in Salesforce. Deleted items will not come into your export file. So this is I think the definitions of data import wizard and data order and these are the data management tools which you can use to upload data and perform other operations also. Yeah, very well explained. I think you covered all the differences and all the key features those are provided through data loader. So I just want to pick one question from the chat. So, Subhashini is asking, we can assign different page layouts for different profiles. So it is clear like if you have different page layouts, we can assign different different page layouts to different profiles. So she's asking like, can you give an example where like where we will be having different pick list values used or different fields, right? So she wants some example. So one example I can relate through recruitment application. So there we created Subhashini, I don't know whether you have followed that project or not. So there we had position object. So we had two positions, technical and non-technical. So for technical, we had some different fields, some common for both technical and non-technical and some were different. So other than this, if you have any example handy, so if you can explain that, so that will be. I think currency can also be one of the example on any object, be it lead account or any object. If currency is there, you would want to restrict the visibility of the users to choose only Indian currency if they are in India. And US users should be able to see only the currency which is USD. So that is another example where you need the pick list values to be restricted in order to have more accuracy in terms of Salesforce data. Okay. So next is like some, Dinkar is asking how to create object and fields with Excel sheet. So if I remember correctly, like when we try to create an object, so there is one option, object from spreadsheet, something like that. So I think through that we can create objects and fields. I have never created although. So Dinkar, you just need to identify some format. Pulwar, do you have any insight on this? Yeah, even I haven't tried that option. I always choose created object directly, but I see that option as well there that you have the option to create object from spreadsheet. Right. You can try that. Yeah, Dinkar, so that option is there. You just need to explore like what should be the format of your spreadsheet and then you will be able to create object and fields through spreadsheet. Siraj is asking what is hard delete in data loader? Hard delete in data loader. Okay. So two types of deletes we have hard delete and physical delete. So if you are deleting something, it will be stored and recycled bin, which is physical delete. Hard delete means it will not be stored anywhere in Salesforce and it will not be stored and recycled bin also and it will be deleted and you won't be able to recover it. That is hard delete. Yeah. Yes. Yes. I think hard delete is available in data loader, right? Hard delete option separately is not available in any of the data management tool. It is just the term or the concept which we need to understand. There is no operation present in data loader for that deleting specifically things as hard delete. Right. Okay. So let's jump onto the next question. Okay. So there are two questions. One is how can we make a field required? So what are certain ways through which we can mark a field as a required? Okay. I'll give you a nice answer for this because we have four types, four ways through which you can make the fields required. First one is through the field itself. You have a checkbox always make the field required. If you check that box, the field will be required at all level. All the users, all the profiles will see that field required. And another option is through page layouts. You can go to the page layout over your mouse onto specific field and you will see required checkbox there also. So you can make the field required there but it will be applicable to the profiles whom you have assigned that page layout. Right. The third option is to make the field required through profiling also. You can do it through FLS, field level security. Once you go there, you have the option to make the field required at profile level also. Then you have the option to make a field required through. Sorry for that, just to correct. From profile, we can make read only. Read only? Yeah. Correct. We can make read only. Right. Another way is to make a field required through validation rule. If you have any criteria, then also you can make a field required. Okay. And one more is trigger. Like through trigger also, we can apply validation. So and in recent release, winter 24, we have that error message in record trigger flows as well. So I think through flows also this can be done. I have never tried because this feature is about to come with this release. Now from record trigger flows, we can send an error message on the record. So I think validation we can apply there as well. Okay. Now we discussed about required. Now next is read only. So what are different ways to make a field read only? Yeah. So you can make the field read only through page layouts and profile. These are the two options through which you can make the fields read only. Okay. And page layout. Okay. And profiles, profiles or permission set. Right. And I think through validation rule also, we can make it read only. Like if you are changing the value, we can throw a validation rule. Like you are not able to modify. And similarly, like through trigger also, like these are workarounds. Okay. Yeah. So, so Siraj is asking what is the advantage of using flow. So Siraj will be having another session for flow, a specific session where we will be discussing about flows only. Okay. Now jumping onto the sharing and security. So first briefly explain the sharing and security model, like what all layers are available. Don't explain the layers because for that I will be asking separate question. You just need to tell like what all layers we have and also before telling the layers, if you can tell like why security is required with any real life example. Correct. Correct. That is more important that why security model is there in Salesforce because I believe security model is the root of Salesforce and there are lots of layers in it. And there is a reason why Salesforce is providing these many layers just to make sure that the data is secure in Salesforce. So let's try to understand that why security is important. Okay. So for example, there are lots of users working across the globe in Salesforce. There is one company who is using Salesforce and there are lots of users, some of them are working from India, some of them are working from US. So we always want the users to see their own data. If a person who is sitting in India, they will try to access the data of people sitting in US. It will be a mess and if they make any changes on their data accidentally, then there will be a huge loss which a company will be bearing. So in order to avoid such scenarios, people have the security in place in companies so that data is visible to the respective owners only whom they are responsible for. So we have record level security and object level security. So maybe I can cover all of these things in the next couple questions. Yeah. So like just to summarize, if you have more than one users, then basically sharing comes in the picture, right? So if you have more than one users and you need to share data of one user with another user, then sharing comes and to prevent sharing and to restrict sharing, we need security model, right? And it is similar to our homes. Like if you are alone in home, so you don't need to apply any security because you don't need to share anything with anybody. But if you are living with your parents, siblings, then certainly you will hide something, right? So if you have more than one users around you, then sharing and security model will be available in the picture, right? So now I just want to understand the difference between object and field level security, like why it is required in Salesforce. Okay. So object means when you have created an entity in Salesforce to enter your data. Now when you have entered the data, then you will need to secure your data as well. So field level security, which also known as FLS, it is just to secure your fields. It is not a part of OWDs or any other layer. But for a field, Salesforce has provided you a separate security layer where you can protect or restrict the visibility of certain fields. For example, in previous question, we discussed about sales process and other aspect where we were hiding the fields through report types. If you want to hide the field from our level itself or on certain profiles, then you can hide the fields from the users also on the profile. That is known as field level security. So there is no difference between object and field level security. There are two different concepts. Once you create the object, you need something to protect the fields and restrict the visibility, which is done through field level security. Okay. So I just want to deep dive. So if we talk about object level security, so what all securities are there? Right. So when we talk about object level security, these can be managed only through profile and permission set. And you have credit permissions, which we give through profile, create, read, edit and delete. And which is required, which gives the users to access their own records. If they are the owners, they will be able to access their own records, whatever permission you give. If you give them create permission, they will be able to create the records. If you give them read permission, they will be able to only see the records, edit and delete, respectively it works. But on the top of that on profile, you have view all and modify extended admin permissions also. If view all permission is provided to a specific profile, those users will be able to see each other's data on the top of every security model. And same goes with modify all permission that all the users will be able to edit each other's data. If you give them modify all permission, that is specifically on that particular object. If account has modify all permission on any profile, users will be able to see and edit each other's data. So these are some credit permissions and view all and modify all permission, which we can give through profile. Let's come to permission set now. Permission set. For comparison of profiling permission set, I have different question. So now you just need to focus on like for fee level security, what all permissions we can manage either through profile or permission set. All right. So you can give two types of permissions, either you can make it editable or you can make it hidden or you can make it read only the other permissions which you can manage through fee level security. Right. So there are two checkboxes. Like if we check both, then it will be editable. If we check one, it will be readable. And if we uncheck both, so it will be hidden. Yeah. Nicely explained. Okay. Now, you can compare profiles and permission sets. Right. Salesforce is so vast. It's really difficult for us to, you know, by advocating questions into, I can sit whole day and explain everything. So, yeah, let's come to profile and permission set. The difference is profile is something. Let's try to understand with an example. So for example, you have a postpaid plan and you are using a family plan. One of the family member needs some extra GBs of data or they need some extra color tunes. So we will not go and change the family plan for just one extra stuff. We will just give some add on to them. So similarly, we have permission set whatever permissions you have given to a user through profile. If any specific set of users need some extra permissions as add ons, we will use permission set. For example, you have a set of users marketing user who are using the marketing profile. One of the user need an extra permission to export the data. So we will go and assign a permission for exporting data and we will assign it on a user level. The permission sets are assigned on a user level. So that is the advantage where you can expand the access on the top of profile or without disturbing the profile, you can simply give the access. Right. Yeah, go ahead. Yeah, I can add one more aspect to it because a lot of people ask why can't we directly change the profile of that user rather than assigning them permission set. So that's going to be that's not a good practice. That can be done, but that's not a good practice because when you have a simple way to assign extra permission, so it's not a good idea to change the profile. And in some of the additions, you have profile limitations also like in professional edition, you can create only two profiles. So in that case, if you want to give extra permission to someone, you will have to use permission set. So there is one example Vikrant is giving like in bank, we require fee level security. So it is nicely written here like few fields are hidden. Right. So that is fee level security actually. And someone is saying sharing and security not applicable with best friends. So like some, some security still we apply. No matter whoever is our best friend. Right. So we have something to hide. So and okay. So now next question is can we assign more than one profiles to one user? No, no, it's a very commonly asked question to people, but we cannot have one user with multiple profiles. However, vice versa is possible. You can assign one profile to multiple users. Right. And can we assign more than one or one like one zero one or more than one permission sets to one user? Yes, absolutely. Multiple permission set can be assigned to a user. Right. And one commission set can also be assigned to multiple users. That is possible. Okay. So for profile, this is the restriction like one user can have one profile, but they can have any number of permission sets. It can be zero as well. And can we remove profile from user level? Profile is a mandatory thing. You cannot create a user without a profile. This is also interview question has been asked to me also. So it's good that we're covering up. All right. And next is permission set group. So what is it? Right. So permission set group rather than assigning multiple permission set, you can create a permission set group where you can add set of permission set. And then you can assign a group to a user instead of assigning multiple permission set. For example, if you have three permission set, one is for report access, one is for export access, one is for contact access. So instead of assigning three separate permission set, create one particular permission set group, add all those permission set into that group and assign that one group to a user. Right. And if we assign permission sets to that permission set group, so we can assign permission set group all together. So can we assign those individual permission sets as well to other users? Yes, we can assign individual permission set as well for the users. So individual permission sets will also be there. And if you want to assign them combined, so we can assign single permission set group also. Okay. Yeah. So I think it is very useful. And in real time projects, I think I have used permission set groups a lot because whenever we are creating a user and we need to assign lots of permission sets, so instead of assigning those individually, we can create a group and we can assign that. Right. And that feature was recently added. I think three, four, five years back. It was not there earlier. Yeah. And somebody is saying when we are working with the large projects, so better to use permission set rather than profiles correctly set and just to update all the viewers like soon, maybe like upcoming one or two years. All the permissions will be shifting from profiles to permission sets. So profiles will be having only baseline permissions like system permissions or gender permission. All other object related record type is layout. All these permissions will be shifting to permission sets. Right. So anyhow, all the things in future, we will be controlling through permission set. So if you are working on any project in any company, so try to have minimum permissions on the profile and maximum permissions you need to give through permission sets. Right. Because we can add permissions at any time. We can remove that any time. So and we can assign. So this is another question to you. Can we assign permission set through automation or maybe through floor trigger? Have you done that? Yes, we can do that. And with the help of data loader also, you can assign permission set to the users. Yeah, I think we can create some records and basis on that because if you're creating profile permission sets, so these are also records. Right. So these are, sorry, these are basically objects and for them, some records will be created. Right. So there are two types of object if we talk about standard object. So standard objects are also bifurcated like setup object and non-setup objects. So these are basically setup objects. So user permission set profile. Right. These are setup objects. You won't be finding profiles and permission sets objects in object manager. Right. And non-setup objects are like account contact opportunity. So these are non-setup objects. Okay. Yeah. So Vijay is asking it. It is enough for a fresher to complete your bootcamp video. So absolutely yes, because you can see today we are doing 96th video and this is eighth month and in this month, I think this bootcamp will be completed. So soon we will be having day number hundred. So I think it will be last session that I will be delivering under this bootcamp other than that, whatever sessions I will be doing. So I will be planning them separately. Okay. So moving on to the next question. I think some issue with the internet. Are you able to listen to my voice properly? Yes. Your video is stuck. Yeah. So next question is for record level security. Like what record level security is, what is the need and what all levels we have so that we can secure data and we can open up the permission. Right. Right. So record level security is required to protect or restrict the visibility or expand the visibility of your records. So object level security you have already controlled through profile and permission set. Now we need to store or we need to protect or expand the visibility of the records. Records are whatever accounts you create, whatever contacts you create, whatever records you create under the object. So you will be now storing or you have already stored the records in Salesforce. Now it's time for you to expand the access. So record level security can be managed by the management hierarchies through OWD's or quite default settings through manual sharing, through teams sharing sharing rules and through territory management or territory sharing. So let's talk about role hierarchies. So role hierarchies are basically a roles which you assign in your company. For example, you have a CEO. Under that CEO, you will be assigning the role of CFO, CTO, and then you can do and then you will have managers, sales reps, agents. That's how the role hierarchy is defined. So you are just managing the access of the records through role hierarchy. So whoever is on the top in the role hierarchy will have full access to the person who is below in the role hierarchy. So if CEO is on the top, he will be able to access the records of all the users who are below him and the manager and the team members, if you have defined hierarchy between them, that means the team member will be able to access the records of people who are reporting to him. So the normal role hierarchy, what we follow in general is managed in Salesforce and it controls the record visibility, that is role hierarchy. Then we have, are we covering it separately or should I explain in this? Yeah, you can explain continuously. Sure. So then we have OWD, which is another layer of Reconnable Security, which is org by default, where you have four types of OWDs. You have private, public read only, public read write and public read write transfer. And there is one more controlled by Payret. So if it's OWD is private, that means you are controlling the visibility and records will not be visible to the users. They will be able to see only those records, where they are the owners. Public read only means the data will become read only. Read write means the users will be able to edit each other's data. And transfer is applicable only for leads and cases, where users will be able to transfer the records also. And then you have control by parent, which is applicable for parent child relationship. Whatever OWD is followed by parent, it will flow to the child object automatically. And that's how OWD is managed. This is applicable to the whole one row. This is not specific to profiles or users. Then if you biblicated more, you will have sharing rules. If the OWD is private, the data is not visible to anyone. Then you need some expansions to expand the data. Then you will use sharing rules, where you can share the data with the help of two types of sharing rules. You have criteria-based sharing rule and you have record-based sharing rules. So record-based means you are sharing the data amongst the public groups, amongst the territories or the roles and roles and subordinates. And criteria-based means if you have specific field which you have set up, like you want to share the data, if the country is India, it should be shared with some particular cues or users. Like that, you can have some criteria. So that is one another way of sharing the data through sharing rules. Then you also have manual sharing, which means manually you can share the data. If you go to any particular record, you will see sharing button and you can just click on it and share it with any public group or users also. Then you have team sharing, which is only applicable on opportunity and account. You have account teams and opportunity teams. Just set up some users into that team and add the opportunity team to as a related list onto that opportunity and the whole team will get access to that particular opportunity. And then we have territory model also, which is another feature of way of sharing the model, where you can have some rules set up on the account and territory model works only on account and opportunity. So you can set up some territory-based rules on the basis of if the accounts are in South region or North region, you can share those specific data with some specific set of users that can be done through territory modeling. Right, so if I summarize, so for restricting record sharing, we have OWD, right? And to open up record sharing, we have role hierarchy, we have sharing rules, we have manual sharing, we have teams, right? And we have territory management, right? Okay, so I think with this explanation, this record sharing is clear. So one question, now I just want to relate object security and record security. So on, for example, on profile, on object, we have just read permission, right? And on record, you have given read-write permission. So will that particular user be able to edit that particular record? Which is- No, profile overwrites everything. If a person does not have edit permission on the profile level, then record level security will also not work. Now, another question. On profile, we have edit permission, right? On record, we have read only. So will that user be able to edit the record? Yes, if it is open through profile, then the access will be given to the user, edit access. So just to add on here, like if you are having edit access on profile, but on record level, like if you have read only. So in this case, that will win because we have to read only and read write. So read only will be, like it will be read only because at top, we have edit, but the records which we are sharing, like opening up OWD and we are defining like it is read only, so it will be read only. And the records which are not shared through that security, record level security mechanism. So those will be available in edit form as well, right? So if you are opening up records security and you are saying like read only, then it will be read only if on profile, you have edit access. So this is a tricky question and sometime in interview, like people get stuck, so that's why I asked. And one more question related to that. It is also a little bit complicated and to be frank, someone asked me this question and at that time I was not knowing this fact, right? I was also got confused. So let's say OWD is private. So OWD is private means you can access the records which you are owning, right? So you can only access those records which that particular user has created, okay? So now OWD is private. So can we open up a record sharing through profiles? Yes, we can. If we give a view all or modify all admin permissions through profile, we can expand the access and open it up. Right answer. So when someone asked me, I was not able to click like through profile also we can, but later on I just got to know, like through view all and modify all, view all modify all basically overrides all the record restrictions, right? So this is also important question that you need to know. Okay, so moving forward, okay, one more question. What is a public group? Because in sharing rule, we use public group. So what is basically public group? Right, and let's also talk about what all we can use in sharing rule. So if you are trying to share the data between the users, you cannot do it directly. You have to use it either roles. You can share it amongst the roles and roles and subordinates or you can use public groups or you can use queues. These are the only options. So public group means you are just creating a group of some set of users and you are sharing the data amongst these. So public groups are specifically used for sharing the data and you can add any users and add as many users as you want in public group. For example, if you have some set of users who are working in India, you will create one group of users, one public group name it as India users and add all those users in that group. One public group you can create for US users and add all those users into US user and you can share the data amongst each other with the help of public group. Now, do we have another question for queues? What is a queue? Yeah, you can just compare public group with queues because queues are available in service cloud and it is very useful. And we get confused between what is public group and what is queue because both are set of users. So, and while you are creating a sharing group, you will get two options there. You can share the data with public group as well as queues. So queues is also a set of users but you will have queues specifically for leads and cases and you can assign the leads to a queue as owner. That's the difference. However, public group cannot be a owner. So in order to simplify this, public groups is also a set of users which is used in sharing rules to use to share the data. Queues are also a set of users. However, queue can be the owner of a record and once the set of users get access to that queue, they will be able to access those particular leads or cases also where you have made the queue as the owner. So that is queues and public groups. So, someone is asking if OWD on account is private and on permission set on account is read and create then which access is working on account. So, basically here OWD is private. So it means that user will be able to access the records which are owned by that particular user, right? So if you are the owner, basis on your object level permission like read and create, you can perform only two operations, right, Purva? Yes, right, because profile, let's understand this profile is the head of Salesforce. I have learned like this only. Profile is the father of Salesforce, profile is the head of Salesforce. It overwrites everything. So if a person does not have access through profile, then it will not be open up through any other record level sharing also. Right, and Sira's owner-based sharing rule, owner-based is basically like you need to decide who is owner of that particular record. So for that we need public groups or maybe roles or hierarchies, something like that. Okay, so I think it was a good discussion Purva. So we covered a lot and I just throw, I thrown some difficult questions as well and like you answered very well. And I think with the help of these explanation examples, those who are watching these mock interview sessions, they will be able to prepare them for the interviews, right? So with this note, like we will be having one more session maybe tomorrow or day after tomorrow and that will be dedicated to flows, right? So flow is basically very difficult topic and question will also be difficult and challenging. So we'll try to discuss guys amongst like in front of you so that you can also learn like how to answer those kind of questions. Okay, so with this note, we are ending the session here only and if you still have any question, you can ask it in the telegram group. I will try to answer them. Okay, so anything Purva that you want to add before we end the session? No, not for now, but yes, I would advise this to people that please go through reports and dashboards also. There can be some questions related to reports and dashboards also, which I think we should also cover tomorrow or day after tomorrow maybe because there are some questions which where people will be confused if they are asked to create some reports or types of reports and stuff like that. So that is also important and automations anyways, we are covering tomorrow. So yeah, that's a good name. Okay, so I can see a few questions that I want to take. So Avinash is asking, can we create users in one shot? So yes, you can create by importing the Excel sheet. If you create Excel sheet first and then you upload that into Salesforce. So like together you can create multiple user records. And Anadi is asking, I assigned an object access through permission set to a user but still tab is not visible. So for tab, we have separate permission. You need to enable that. And Vikrant, if you follow all the mock interview sessions, I think these are enough for preparing admin interview. Srikanth is wishing teachers day to us. So yeah, happy teachers day to Purva as well. I wished in the morning to LinkedIn. Okay, so Vijay, you have filled the form, you didn't receive any emails. So by the end of this week, I will be sending some emails to all the folks. Okay. Yeah, now like folks are starting, folks have started wishing teachers day. So Anadi Raju, thank you. Okay, so thank you so much guys. See you tomorrow in another session with new topic. Okay, thank you Purva for joining the session and sharing your valuable insights. Thank you. Pleasure to all of my happy teachers day. Bye bye. Bye everyone.