Pass Salesforce Certified Advanced Administrator Exam in First Attempt Easily

Security and Access

1. Course Introduction, Exam Guide and Security and Access Introduction

Thank you so much for checking out my Advanced Administrator Certification course for the Salesforce Platform. Now, I wanted to get started with getting youfamiliar with where to find the exam guide. Salesforce recently added the exam guides to Trailhead, and so I wanted to point your direction towards Trailhead to show you this new tab called Credentials. So click on the Certifications link from the Credentials tab, and it defaults to the Administrator section for the different administrator credentials that Salesforce has. Now, for this course, it is the Advanced Administrator course. So you want to click on Advanced Administrator to get to the exam guide for the Advanced Administrator Certification exam. Let me show you this exam guide. It's important for you to know where to find the exam guy because Salesforce recently moved that away from where it used to be and moved it to Trailhead instead. Now, even though we're in the Winter 19 release at the time of this recording, this exam guide is for the Summer 18 release. And so the main thing to point out here is that I structured this course after the Exam Guide in the different knowledge areas that you'll find. Now, I've elected to separate out this certification into three separate courses, and this is part one of a three-course series. I'll be releasing Part Two next month and Part Three the following month. And so depending on when you watch this, look for parts two and three or just stay tuned; they should be out shortly. Now, part one of this three-course series related to the Advanced Admin Certification covers the first three knowledge areas, which are: secured and accessible with a weighting of 20%; extending custom objects and applications with a waiting of 8%; and auditing and monitoring with a waiting of 6%. Now, I've just finished recording these three sections, and so I can speak about what else we cover. And rest assured that in each of these knowledge areas, I cover each bullet point and everything that's mentioned in them, plus a lot more as well. The first knowledge area is security and access. And as I mentioned, it's 20 percent of the entire exam. It's the largest knowledge area as far as waiting goes, and it's also a huge section of this course. There are over 30 lessons in this knowledge area where I go in depth across all these different concepts related to the sharing model controlled by parental grant access by hierarchies profiles versus sharing rules, community security settings, and so much more. I get into territory management. I do a lot of lessons around territory management, the territory hierarchy, and how that impacts your access as well. We also cover profiles, permission sets, and delegated administration. And then as we move into the second knowledge area where we extend custom objects and applications, I felt it important to actually build out an application in order to demonstrate all that's contained in this one singular bullet point, which says to describe the appropriate use of relationship types when building custom objects. And that's the master detail. And look up. So, in this knowledge area, we create an asset management application. And so we'll be building several different custom objects and junction objects. And we're dealing with different types of assets. So that spans across multiple record types. Some of those assets include medical equipment, and other assets include office equipment. And so we work through the process of being able to assign these different assets to either employees or a room, for example, or to both. We look at the implications of also converting these different relationship types back and forth between Master Detail and Look Up. There's a lot of nuance here. In this course, I go into depth and knowledge area two, and then finally auditing and monitoring the final section of this course. And the third knowledge area, which gets into a lot of the different tools that you use to monitor the platform, And I go into more than just the setup audit trail and the debug log indicated here. In this bullet point, I also delve into email log event monitoring and session management. So I do encourage you to get enrolled today and start your journey down the path of becoming an advanced administrator on the Salesforce platform. So now that you know where to get the exam guide for the advanced administrator exam, let's dive into that first knowledge area, and let's get started with security and access. I'll see you there.

2. Salesforce Security Model Overview

The first knowledge area of the exam guide is security and access. And one of the core things that you need to keep in mind as we look at an overview of the salesforce security model in this lesson is that to be a successful advanced administrative specialist and to pass the exam, you'll need to have a much deeper understanding of the security model of salesforce. And so I've searched for the terms "users" and "setup," just bearing in mind that security begins at the user level, and there's so much that Salesforce determines as far as what you can see or not see based on who is trying to log in. And so I'm on the user's list here for the users that are in my own Salesforce.org. I recently signed up for this organization. This is a free Salesforce account, and beyond my own user account, there are a few other default user accounts that may or may not be in your own Salesforce instance, depending on when you signed up for a free Salesforce account. And you'll notice that some of the usual suspects come to mind when you think about security: you know you're going to need to understand profiles, you know you're going to need to understand roles, and you also need to understand the licence type. So if we were to go into one of these users, and I'll just go into my own user account here, you'd see that there's this user licence for Salesforce. Now, I've already specified a role for myself in the role hierarchy. We'll be getting into profiles and roles and the different types of user licences, as well as some of these checkboxes on the user account as well.But then beyond that, We'll need to discuss profiles and permission sets. Public groups. Queues. In addition to what I previously stated Roles in the role hierarchy and then other complex things that are more involved that are not on the administrator exam and things I've never covered before because of this advanced administrator course This is the first time that I've recorded a course for this particular certification. And so this diagram can be found, and this is, I think, a great diagram about just a great overview of the security model of Salesforce. And I've seen other versions that kind of stop at the manual sharing level. And this particular diagram is inside this document, known as a Guide to Sharing Architecture. I'll link to that as a resource below this lecture. And then you can always get to the different versions of this documentation by clicking the down arrow and selecting which release you would like this documentation for and even what language, such as English or Japanese. And then you have the HTML online version, or you can download a PDF as well. And so if you want to be able to follow along with some of the security-related information or supplement what you're learning here, I do recommend this guide to sharing architecture. This is intended for those interested in becoming architects. And ultimately, this is one of the designer certifications where this guide to sharing architecture is really used. But I felt like a lot of this information is relevant at the advanced administrator level, and it does get deeper in the weeds as far as some of the programmatic ways that you can share records. But this really is a diagram that feels like it belongs in the advanced administrator course. And so to make sense of the Salesforce security model, you see that at the very base level, our profiles and permission sets are assigned to a user. A user can be assigned one profile, and you can be assigned to multiple permission sets. We are going to be taking this from a kind of bottom-up approach as far as talking about users and licence types. And then we'll discuss profiles and permission sets, and then subsequently throughout this section we'll be talking about organization-wide defaults. Then we'll address the roles and hierarchy and their implications there. We'll then go into sharing rules and some of the implications behind manual sharing. Then we'll talk about teams and team access. And then I'll introduce you to territory hierarchy access—which has to do with territory management as well. Especially as you progress up the levels of this sharing architecture diagram. These are things that are not broached on the admin exam. And so it is here that you'll really get a lot of new information, but I'm going to add additional depth to all of these areas. One of the nice things about creating this advanced admin course right after recording a new version of my Salesforce administrator course, in which I recently recorded all that enlightening experience, So that's a brand new version of the admin side of things. As I know where I left off with the admin certification, I'm not going to be repeating a lot from my new administrator course. And so if I were to do anything to update this diagram, I would add the term "users" down here to show that the security model really begins with the user level. And then from there, we work our way up. You'll notice these arrows here. As you go down this upside-down pyramid, the security model gets more precise. And on this side, as you go up a level, it shows or denotes wider access. So, in terms of a high-level overview of the security model and Salesforce, the most important thing to understand is that you set things at the base level of security in general as the most restrictive level that is required. Then, as an advanced administrator, you can gain additional access by modifying all of the various security components that are available to you. And so now that we've looked at a high-level overview of what we're in for in the security and access knowledge area, which, oh, by the way, is by far the most heavily weighted knowledge area of the entire exam, I do believe that if you understand fully these concepts and those of security and access, you should be able to pass the advanced administrator exam just fine. You will greatly improve your odds, at least. But now that we have this overview and we've kind of set the table for what we're getting ready to dive into, we're going to start at the very base level, and that's at the user level. And that will be in the next lesson.

3. User License Types

Set up and search for company information, and click on the link here under Company Settings that will bring you to your company information screen. And it's here that you can see the different user licences available in your organization. And one thing to note is that your company name, as it appears here for your organisation name, would be the name that you entered when you signed up for your free Salesforce account, often known as a free Salesforce Developer account. And so if you are trying to go through this course using a workplace.org or a pre-existing salesforce.org that you've signed up for previously, I do encourage you to start fresh with a new FreeSalesforce developer account to avoid any potential conflicts. There's no rule against having multiple free accounts on Salesforce. They encourage those learning the platform to sign up for as many sites as they need. So you're never going to have someone chasingyou down from salesforce asking you why youhave a dozen free salesforce developer accounts. And so with that, if you look at the "User licenses" link and hover over it, it will take you to the User licences area. Click on it, and it'll scroll you down to the specific area where you see a lot of different types of user licenses. And so I mentioned previously that security begins with who theuser is that's trying to log in and what licence theyhave assigned that dictates a lot of what they have accessto or what they don't have access to. And you notice that the top licence type is Salesforce. A free Salesforce account includes two licences in total. One is used for your own account that was set up out of the box when you signed up for this free account, and there's one remaining. And below this, another commonly used licence type is Salesforce Platform. And people frequently get these things mixed up when creating a new user account. And if they have already burned through their two available Salesforce licences and are trying to add a third user, they don't see the selection to select a Salesforce user license. So you can see more of these licence types by clicking on Show More. And this may vary, but you'll see that there are a lot of licence types available for chatter-free, for example, and then there are others that are kind of limited. But this will give you the ability to create user accounts around some of these different licence types. And I'll provide a resource down below this video that goes into all the details around these licence types. And actually, you can just access it here. It's the User Licenses Help, and that should open up in a new tab. And this gives you all the ins and outs—more than you'd ever care to know about user licences in SalesForce. And this is great reading material if you ever have trouble falling asleep, I might add. But here's where you can get more information about the different licence types. And I wanted to highlight that if you go under "standard user licenses." This is where you'll find salesforce, and there are two of those available in the free accounts, as well as salesforce platform. And so, Salesforce Platform is different in that the main overriding difference is that the Salesforce Platform licence type is designed for users who need access to custom apps but not the standard CRM functionality. And so let's go into our Salesforce instance and create a new user, and I'll show you or remind you of how to assign users to a license. And many of you may already know this if you've done any work on the platform or passed the admin exam, but I want to highlight a few things here and also emphasise that this is work that we need to do. I try to get you hands-on opportunities to do some actual work inside the salesforce early in the course. So we're not spending hours talking conceptually, but we're layering in some hands-on experience from the beginning. So we're going to create a user record named Jim Doe. And Jim is starting to become famous in certain Salesforce circles. He's still not quite to the level of the better-known John Doe or Jane Doe, but we're doing what we can to get Jim the recognition that he so desperately deserves. For the email address, I do encourage you to enter an email address that you have control over. Use a personal email address; never use a workplace email address for anything that is related to your learning endeavours or certification pursuits, because if for whatever reason you were to leave that employment, you would lose access to that email address. And that could have some dire consequences if that email address is tied to your trial head account, your identity online, and your certifications. So, do use an email address that you control. And then for the username, I would do something similar to what you use for your primary login on this.org and then I would just put adot and then something at the end of this. This user name has to be unique across allsalesforce instances across the globe and throughout history. So if you have a lot of different user accounts, you'll want this to be unique. So I usually just do a dot, and then I add some sort of designating factor to this, and that way I can log in as this user with a username and password. And I'll also be going over how to log in as a user just within the Salesforce interface, not requiring a username and password, but as an administrator. But I do like to have the ability to receive those emails that are intended for this user as well. For testing purposes, I want to add a "J" on the end of this, and then the nickname has to be unique as well. And so I think that I've probably already used this nickname on this.org, so I'm just going to say SUP. And the nickname just has to be unique within your own org, not across all Salesforce organizations. So here is the user licence and what I was talking about as far as Salesforce versus the Salesforce platform. And so for the second user account, we want to select Salesforce. If you don't have Salesforce available, then a lot of times users will select Salesforce Platform, and that hoses the profile selections. And so I have students previously they've gonethrough my courses saying I'm not able toselect the profile that you said to select. And so the question is, well, what licence are you selecting? So be sure you select Salesforce. And then for the profile for Jim Doe, we're goingto select a custom profile of custom marketing profile. Now we'll be going more deeply, trust me, into profiles and roles momentarily, but I wanted to at least specify the settings for this particular user. So we're going to put himin the Western sales team role. That's just the bottom one here. In my instance, the role hierarchy in the customer marketing profile will make him a marketing user. And it is a good idea to become familiar with them as well, because remember, we're talking about licence types and security beginning with the user. Understanding what designations are available at the user level and which are available through profiles, through roles, through permission sets, etc. So I'm going to check a lot of these insofar as marketing, user knowledge, user flow, user service, and cloud users; I'll leave the rest alone; and then I will make sure that it's checked to generate a new password and notify the user immediately and click Save. Now we have created a new user and assigned a licence type for salesforce, so I do encourage you to check out the License Help article to become more familiar with the different types of licences that are available, some of which may appear on the exam. You don't have to know everything, but I do recommend that you understand the difference between Salesforce and Salesforce Platform, as well as some of the other user licences that may come into play on the exam and that I recommend that you understand the ins and outs of. As I go back to company information and look at this licence list to remind myself of all these, I think if you click Go to List, this may throw an error. Okay, list view isn't available in Lightning Experience, so go back, and that's why I was clicking on more previously; just a tidbit from experience, but when it comes to licenses, you've got to show ten more and show two more, I guess. But, in my case, a few of the other licence types on this long list of 22 would be, of course, the salesforce and salesforce platform, and you'll notice that we now have zero remaining licences for the salesforce license. However, Chatter Free is another one that may appear on the exam. And then the community users, you'vegot partner communities that are apossibility and then customer communities. We will be dealing with communities in a different knowledge area, but those will tie in at the user level to a specific licence type as well. So you see that we have customer-community licence types available to us and partner community licences as well. So we'll be putting those to good use later on. But just keep in mind, these licence types are important. They play an integral role insecurity at the user level. So as we get further into security and access and we've discussed users and licence types, we're now going to talk about the bottom point of this pyramid and specifically profiles. Let's do that in the next lesson.

4. Profiles

So remember that users can be assigned to one profile, and I have searched for profile in the set-up menu. That brings me to the profiles list, and any custom profiles are denoted by a check mark, and we see here that there are a few available at the start of a free salesforce account, and these are labelled so that it's clear even from a list view that, if you can't see the check marks, salesforce has custom profiles in the actual profile label or profile name. I would consider this a best practise so that you can see at a glance which profiles are custom profiles, and if we were to go into one of these custom profiles by clicking on it, you'd see the enormity of the different settings you can set on a profile. We're in the old profile layout, and I'm going to show you where to set the enhanced profile layout, and this just scrolls on forever, and all the settings are here on one big screen. Always prefer to go into user management settings and enable enhanced profile layouts, so go to user management, and this did recently change locations, so if you have a lot of experience in the platform and setting this, please note that Salesforce has recently moved this into the user management settings. So, if you see this setting for the enhanced profile user interface, simply toggle it on to change the appearance of the profiles whenever you're in one. Other settings here include enhanced profile list views, which you should enable. There are also a couple of newer additions related to the recently passed GDPR legislation. Salesforce is also added in this area, granting the ability for users to self-deactivate as well as providing, enhancing, or including the ability to scramble specific users' data. And so if you're ever dealing with GDPR-related regulations, you'll want to also become familiar with user management settings. But for the sake of dealing with profiles, we want to be sure that the enhanced profile user interfaces are enabled. There is no save button. It's just a toggle that enables this in your.org If we go back into profiles, we'll return to one of the customer profiles that we were in earlier. The custom marketing profile is now divided into two primary segments: app settings and system settings, as you can see from the new display. And one thing to note as far as system permissions under the system settings is where you would find designations such as "view all" and "modify all data." I wanted to speak a moment about the power of that at the profile level, and you want to use this sparingly because this overrides the settings that you would set as far as object settings or settings in the role hierarchy. As far as the ability for users to edit, delete data, for example, or even view data So "view all data" enables users to view all organisational data regardless of sharing settings. Typically, this is not checked on the profile level, other than for the one standard profile that you typically want to be assigning users to. Now, one thing to note as we look at the customer profiles is that it's considered best practise to not assign users to standard profiles but only customer profiles. The standard profiles have a lot of limitations, and you cannot assign apps to them. There are a lot of reasons why you don't want to use a standard profile. You instead want to create a custom profile using a standard profile as a template. And so, for example, we have these sales, marketing, and support profiles that are custom ones. And I mentioned the one exception to a standard profile: the system administrator profile. Now you will typically have users assigned to the system administrator profile, and that is a standard profile. And in this profile, you will find that under the system permissions for system administrators, they do have you all and can modify all data. And as an administrator, you need the ability, typically, to be able to touch, edit, delete, modify, and see all data. And so you'll see here; I just want you to verify that in your own system administrator profile that you have modified all data and, as well, viewed all data. And so just bear in mind that the system administrator profile is the one standard profile you'll typically be assigning users to, such as yourself. But then for other profiles, you'll want to copy them in order to create a custom profile from them. And then we can click next to see the remaining list of profiles here. So for example, if you needed or had the need to create a custom profile for a contract manager, you could click clone next to the standard contract manager profile and then name it with the naming convention of "custom" in the profile name. And just to be consistent with the others that are outside the box with this, org this freesalesforce.org I'm doing a custom colon space and clicking save, and then from there, you can customise further this custom profile and assign users. So I'll have a link for a reference article on some of the limitations on custom versus standard profiles, and that reference If you click the help link from the profiles list, it's not actually this help article, which has to do with managing profile lists and viewing enhanced profile lists, but it's this link here related to standard profiles. This gives you a better idea of the different permissions that are available out of the standard profiles, and we selected the contract manager profile; this gives you an idea of what is available in the profile settings. And this is a good reference point as well. if you clone a standard profile into a custom profile. This will tell you what the start-up point settings are. Because as we go back into this profile—and this is our new custom contract manager profile—you do have to navigate through and figure out what all these different settings are and what makes this particular profile special or different from others as well. So, if you've taken my administration course or obtained your administration certification, you should be familiar with profile. So I'm not going to go really in depth on this, but more as a reminder that in the app side of the settings for a profile, you can assign different applications to a profile through the assigned apps. You see which apps are visible for a profile as well as which app in particular is the default. Typically, you'll find that the default application is the standard sales application. And then some of these applications—you see the API names here—are Lightning specific, and if it has the word "Lightning" in it, that's a clue that it is a Lightning application. And then there's usually a classic variation of that as well. You'll see that for service as well; there's a service app and a service console app, both of which have Lightning designated in them. And there's also a sales console that's a Lightning app. And so other settings on the profile that I'm going to cancel out of or go back to are in addition to these other app settings, such as assigned apps. Another common place that you spend a lot of time in is object settings. We have control over what is commonly referred to as the credentials from here. Some prefer to refer to it as the Cred rights. That's where we're dealing with create, read, edit, and delete object permissions. And so by profile and by object, you can control and set the object permissions that dictate what profiles can do on, for example, account records. And so you could go into the accounts object for the specific profile that you're looking at. Editing is here so that you can get into page layout assignments and default record types as well. And then there's any kind of object permissions. This would be the create, edit, delete, and read settings and then the field-level security. Now we are going to go more in depth into record-level and field-level access. But I wanted to give you a brief overview, a reminder of the things you can do on the profile, and some of the functionality as well. And there's not a lot you can do as far as editing the properties of a profile. Basically, you can rename it and you can change the description, but you can navigate either through these breadcrumb links to go back or some of the drop-down links as well. So going back really quickly into object settings, some objects you have full rights to, others you have no access to. at the profile level. And then as well, you see the tab settings: default on, default off, and hidden. I go into all that in my admin course. So reference that if you're not sure of the difference on those. We'll be getting into page layouts more later as well. And so you should see all of the different objects and their corresponding rights for the profile, and those can be adjusted. And then going back a level to the profile overview, there are some of these links that you will deal with more as an administrator or advanced administrator than others. And so the assigned apps and the object settings are definitely two areas that you spend significant time in. Then there's system permissions, which are covered in the Admin course in terms of login hours, login IP ranges, and session settings; system level settings are not object-specific, but system-specific. So, if you're feeling unsure about trusted IP ranges, or what's behind the session settings or login hours, or some of the behaviour there, I encourage you to revisit my Admin course. And I'd like to show you that we've looked at the view and modified all data, as well as other things you can do here. If it's not something that's tied to an object specifically, and if it's not something that's set on the user record, usually if it's something more system-specific and more holistic in its approach, then you'll find that in the system permissions, oftentimes it's hard to remember exactly where to find certain settings as well, and you certainly don't need to memorise all these. There is a massive list that's continually changing and growing. And so one other tool tip, if you will, is anytime you're dealing with a profile, you can search inside the search box. So if I wanted to search for all instances where modify appears, you'd see that there are three instances of that. And just looking here under this list of permissions under system permissions, I was going to pull out a word here, this term for Apex Rest Services. Let's say that you're looking for rest—not rest in a hammock, but rest as in Web Rest Services. And so there are two instances there's.The one on this page for system permissions is also pulling in Rest within this word of restrict. So this is dynamic; as you type, it does narrow the results. Well, it still kept the other one in there, but I'll keep typing and then eventually it will narrow it down. Helpful tool. And that's why we want to use the enhanced profile layout that we set previously. So as you think about the foundational settings of security and the security model of Salesforce, you want to just bear in mind a few key things as we move forward because we're getting ready to go into permission sets. And some of those primary things are, and some of these are basic but need to be known and need to be emphasized, that you can only be assigned one profile. It's best practise to assign users to custom profiles, and then in the profile those permissions are divided into two primary groupings: apps and system settings. And you can't navigate and find those through this search box here. So now in the next lesson, we're going to look at permission sets and how those differ from profiles and why. Permission sets are an important piece of the security model.

5. Permission Sets

So, in addition to profiles, another setting that you'll find under the Users menu and setup is permission sets. And as we go into permission sets, out of the box, there are a few that already exist in the Salesforce instance. But rather than leveraging one of these, I want to create a new permission set. And as an example, I just want to create a permission set that gives someone the rights to delete an account. So I'm going to reflect that in the label that I choose to name this permission set after, and then tab it out so that it fills in the API name with spaces replaced with underscores. The API name is something that seemed to be hidden behind the scenes in the referenced incode, and users don't see the API name. And then you need to specify what sortof licence the users will have that canbe assigned to this permission set. And so we're going to select Salesforce. Remember, we're not really dealing with Salesforce's platform. That's a different licence type. We're primarily going to be concerned with the Salesforce licence type. And one point of distinction between profiles and permission sets as we save this permission set Delete Accounts" is that you can be assigned to multiple permission sets whereas you can only be assigned to one profile. And so you notice here, as we're in the Delete Accounts permissions set that looks very similar to Profile, at the top is the App section. Then below that are the system permissions. Now under "System," there's only this one link for system permissions. Contrasting that with profiles, if we go back into our custom profile that we created for the custom Contract Manager profile, for instance, the apps links are virtually the same between profiles and permission sets. But the system there's many morefor profiles than for permission sets. In permission sets, we just had system permissions. And for profiles, you have these systemwide-type settings for the profile. So for permission sets and deleting accounts, what we want to do now is set the object settings for the Account object. One thing to note here is that we have no access to the accounts. And so one thing that people get confused about is that if they assign a user a permission set, they think that this permission set will override the profile settings and somehow take away the access to the account object for those that are assigned to this permission set. In this example, that's not the case. Permission sets enable additional access or rights. If you remember, we start with the most restrictive security model. At the base of all security, Salesforce is the most restrictive, and then we open up further rights and access. In order to grant the ability for users to delete accounts via a permission set, you click on Accounts from within the permission set and then click Edit. And it is here that you change or specify not only the tab settings and field level security, but also the ability to do things. The Crud writes to create, read, update, and delete. And so if I select delete, other checkmarks are going to be checked as well automatically, and that also gives us edit and read. It stands to reason that you should not be able to delete an account if you don't even have the ability to see accounts. It also provides you with the less far-reaching security setting implications of editing. And so if you have the ability to delete an account, you have the ability as well to edit it. So I'm going to click save. And so the thing to bear in mind with permission sets is that you can be assigned to more than one. And here is where you manage assignments. By clicking Manage Assignment, you can add assignments and assign users. So I'm going to sign myself and Jim Doe and select Assign. And so now if we go into a user record, the impact of that assignment of the permission set is that it will now display in that user's user detail. So this is the user's home page. So if we go in here and select UserDetail, we'll get to the User Detail screen for this user, where you can see the profile that they've been assigned to in the role hierarchy and the user license. And then here are the permission set assignments, and we've got the one assignment. So at the profile level, a user may already have delete rights on the account object. Let's go into his profile, which is the customer marketing profile, and go into object settings and see what the credit rates are on his account, which is recreate, edit, and delete. But let's say that for this profile we only wanted those in it to have the rights to only view accounts; they can't edit or delete them. So we could take those rights away at the profile level so that, in essence, account records are read only by users in this profile and then permission sets. One of the underlying factors of permission sets is that they are intended to provide exceptions or ways of grouping disparate users that don't have common profiles. For example, let's say in this example that for each of these four custom profiles, we had 20 users in each, and we needed just one user out of each of these four profiles to have the ability to delete accounts. If that was some requirement that came down from onhigh, we would need to go into each of theseprofiles and take away the ability under object settings foreveryone in these profiles to delete account records. And then for the four exceptions to that rule, we would assign them that permission set. This is a common use case for permission sets in situations where it is difficult to group people together and you want to avoid creating unnecessary profiles. And one of the reasons, as I take away those credentials from those other custom profiles I'll speak to, is that I'm forgetting which ones I've already adjusted. So let me go into profiles, and I've completed the customer marketing, and the contract manager has authorised me to provide customer support. But back to my point, before there were permission sets, users would, in the natural progression of business, see a need for having exceptions to these profile rules, which would lead to a proliferation of custom profiles, almost for each individual user. And I've seen instances where there are 100 users and 100 profiles, and it's a nightmare. So, over time, probably about five years ago, salesforce recognised the need to be able to avoid having administrators create custom profiles for every single user. So they introduced permission sets as a way to handle these one-time exceptional types of use cases, allowing you to assign a user to one profile while handling variations and exceptions to the rule through permission sets. So here's the final profile I need to adjust. So I've taken away, I believe, deleteability for those four custom profiles. And so in this scenario, Once again. as a reminder to kind of level up. in our fictional instance. If we had 20 users in each profile and 19 of them needed to be blocked from deleting accounts, we could do it at the profile level. We would remove the delete credence from the object settings for each profile at the account, and then we would assign a user from each of these profiles to this delete account permission set through selecting "manage assignments" and assigning them there. Now, we're of course limited in the number of users, so we're not able to do that fully. But the main thing to keep in mind is that you can be assigned to multiple permission sets, and that permission sets are similar to profiles in that they are designated with the app settings as well as system settings. There are fewer system permissions and system links down here as compared to profiles. And then as well, any settings that you set in a permission set do not take away access. So for example, once again, if you were to assign someone this permission set, that doesn't mean that they no longer have access to contacts. It opens up additional rights. And so with this setting here, any users that are signed up for this permission set will have the ability to not only read and edit accounts, but also delete them as well.Now that we've talked about it and compared and contrasted profiles versus permission sets, we're going to talk about some concepts we find in both and that can be controlled in both. That has to do with record and field-level access. Let's get into that. If we go into a profile, for instance, and go into the object settings, it is in the profile or the permission set at the object level that we can set these rights for create, read, edit, and delete as well as the field level settings as well. So we'll dive more deeply into Record-and-Fill level access in the next lesson.

Hide