Gain in-depth knowledge for passing your exam with Exam-Labs Certified Advanced Administrator certification video training course. The most trusted and reliable name for studying and passing with VCE files which include Salesforce Certified Advanced Administrator practice test questions and answers, study guide and exam practice test questions. Unlike any other Certified Advanced Administrator video training course for your certification exam.

Security and Access

6. Record and Field Level Access

One of the first points in the Security and Access section of the Advanced Administrator Exam Guide specifies that, given a scenario, you need to be able to determine the implications for record and field data access. That includes a variety of components of the Salesforce security model, such as the sharing model controlled by parent grant access using hierarchies profiles versus sharing rules, among others. And in this knowledge area of the course, we will be going through all those. But I wanted to discuss record and field access at a high level. and that comes to mind as far as thinking about record access. You can restrict record access on the profile level by removing all read, create, edit, and delete rights. If you were to take away all object permissions from an object, then you would see, like as we're looking at a profile, such as this Custom Contract Manager profile, and looking at the object settings, not necessarily for accounts, but for some of these others, that if we were to take these away, then it would say no access. So anyone with this profile would not be able to access any account records. Now, there are also implications for record access as it relates to the role hierarchy. And it's through the role hierarchy that you can have access to some but not all account records. For example, we'll be diving into the role hierarchy, and that's how you open up access to records vertically. And then we'll also be talking about sharing rules and other ways that you can open up access laterally. But as far as record access, the object permissions in the profile are one way of approaching that. And then as well, at the object level, not only the object permissions but also the field-level security And there are multiple paths to field-level security via the profile. And it's here that you can give people either read or edit access for individual fields on an object. Remember, we're on the account here under the Custom Contract Manager Profile that we created previously. And so any of these rows for any of these fields, if only the left column is checked, for example, the clean status, and then the right column is not checked, then this would be a read-only field for this profile. If we wanted to make it so they could edit that field, we would check the check mark for edit access. Now, some of these are not editable because of the nature of the field, such as "Last, Modified By," which is another system type field. Some of these can be set as editable. You know, it's a slight difference in the appearance of these checkboxes. This NAIC code is something that can be checked. And so we can either have it be a field not visible at all to a profile, read-only, or read only or Read Write.And so "Read Right" would be the two check boxes. If we have a hidden field in a profile and first check the edit checkbox, Read is also checked because you can't edit a field you can't see. And so I want to show you as well. In addition to the profile level, you can also go into the Object Manager through objects and fields. I'm not going to save any changes to what we just did there. That's just for demonstration purposes. But if you wanted to go into the Object Manager and then select the Account object and go in from this route, you could go into fields and relationships. You can set the field-level security at the object level. So here's the NAICS code. If we click on this, we can access field-level security by clicking the Set FieldLevel Security button here at the field level. And it's the same sort of concept, and you can specify the field-level security for each profile. You select that individually. So at the profile level you can select all fields for an object, and then at the field level you can select or deselect the visibility, making it visible or read only at the profile level. And so, for example, in this custom contract manager profile, the left one is visible and the right one is read only.So, if we make this invisible for the contract manager, it also deselects the option to make it editable. And so you may be questioned about how you can make a field invisible, not visible, or read only, for example. These are some common questions on these exams, and another common question you'll encounter on the job is whether we want a user to be able to see but not edit this field. and you've got to make a determination. Is this something that we set at the object? Is this something we set at the profile? Or is this something that we set on the page layout? The page layout can also be used to make a fieldread only. And so if we were to go into the page layout, and I'm going into the account layout here, and if we look for this particular field in an ICScode, you have the option in the interface. If we were to add this to the page layout, for example, you can click the wrench icon and make it read only in the page layout. You can also specify it as required. If you do that, you can't make it read-only because it's not fair to make a required field read-only because then if it's blank, the user can't actually enter anything. So we will be looking at all these different ways of making fields required and read only.And you need to understand these different options because we may elect to make a field read only, for example, in the page layout and think that that will do the trick. and that doesn't necessarily do the trick. Now, I just made that field read only on the page layout, but let's say that we were going in through a list view, and if I were to bring up, for example, an account list view, a user can get to records through a list view. For example, if you've not locked that field down to a read-only status for their profile, then they could get to it through a list view and be able to edit records that way. And so these are all scenarios that you need to think about and become familiar with as far as the implications of record- and field-level access. And so now that we've done a very high-level overview of profiles and permission sets and we've discussed record- and field-level access, I feel like it's time to bring out a couple of the sample questions in the exam guide that deal with some of these concepts, and we'll talk through and demonstrate some of this in the next lesson.

7. Sample Questions #1 & #3 from the Exam Guide

So, this first question, this sample question from the exam guide, is about fill level security. And I felt like this was a good point to get into this. Question three and four are also similar. And so we're going to go through both of these quickly. Keep in mind what we've learned thus far. And so the fictional company of Universal Containers has a custom field on its contact record called Salary that is hidden for all profiles except the system administrator. The administrator has been asked to grant only recruiters and assistance access to the salary fieldto the recruiters and assistance.The recruiters and assistants currently have two different profiles. So which two should the administrator use to meet this requirement? and so choose two correct answers. One thing I want to note is that this is not necessarily a misdirection, but it's a given that if a field is hidden from all profiles, then the exception would be the system administrator. And that's because the system administrator, by its very nature, can view and modify all data, so they have access to this field. Depending on your tolerance level for story problems and slight misdirections like this, this may confuse you a little bit as far as some of the designations here, in that it is hidden from all profiles and then you as the administrator are being asked to grant read-only access to this salary field for recruiters and assistance. And so it does inform you that there are two different profiles. One is a recruiter profile, and one is an assistant profile. So what should you do in order to open up read-only access to the salary field to recruiters and assistants? So the options are: a) to change the access levels in the recruiter and assistant profiles to read only for the salary field; b) to create a sharing rule for the Contact Object using criteria-based sharing on the salary field. C would be to create a permission set with read-only access to the salary field and assign it to the assistant and recruiter users. And D will be responsible for creating a new profile for the assistance and recruiters, as well as reassigning these users to the new profile. Now, sometimes you can approach this in one of two ways. You may just know the answers right away, or you can, through a process of elimination, identify things that cannot possibly be right. And that's a good strategy to use when taking the actual exam: throw out things you know aren't true. Creating a sharing rule for the Contact Object using criteria based on sharing on the Salary field is one good candidate that cannot be the case. One thing about sharing rules, and we'll go into this more later as we get into sharing rules, is that sharing rules cannot be used to modify field-level security. Sharing rules are intended to allow access laterally rather than through the role hierarchy for those above or below you. But it's more for those who are in a different branch in the role hierarchy, for example. But it's the lateral access to the actual record that's important. But it's not opening up access to the fields on an object; it's dictating what records someone might have access to. So you don't specify field-level security through a sharing rule. Also, as previously stated, we want to break the habit of creating new profiles just because, and whenever there are some out-of-the-box options that you can use instead of creating a new profile, you want to do that instead. And so the right answers here are A and C. And before I go much further, let me verify that by looking at the answers and showing you where to find the answers in the exam. Guys, if we scroll past the five questions here, we'll get into question three here in a moment. But past the five questions in the exam guide, we will find the answers, and I'll try to not reveal the answer to question three quite yet. almost revealed it. So it's A and C, as I mentioned. And so back to question one. We would go in and change the access levels in the profiles for the recruiter and assistant. Another thing that makes us not great is that they name these profiles "recruiter" and "assistant" and capitalise them here. But in the actual question, it's lower case, and it's saying that you need to grant read-only access to the salary field to the recruiters and assistance. The recruiters and assistants currently have two different profiles. It's a little misleading because you're like, "Okay, the recruiters have two different profiles, and then the assistants have two different profiles." They don't say or spell out that there's a recruiter profile and there's an assistant profile, which they would hint at. That sounds a little better if it's capitalized. But I digress. So you could go into the actual profile and set it to read only the salary field. Or you could create a permission set and set it to allow only access to the salary field and assign it. So it's the same sort of concept, either at the profile level or in the permission set, and then assigning it to the user. So if, for example, let's see where I'm at here, If I were to go into the Object Manager, I just happen to be on the accounts listview. I'm going to select Edit Object to get into the Object Manager for the account object. In our sample question, though, it was on a contact, but I'm just going to demonstrate this on the account. So you would go into the object in question, which would be contact. In that scenario, I'm on account. But then you would go into fields and relationships. You would identify the field that you're wanting to set field-level security for. And in that sample, it was salary. I'm just going to select this field again, which we dealt with previously. Then you could set the field level security, and everything would have been invisible and looked like this. And then you could have gone in and located the recruiter and the assistant, which, I believe, was the assistant. So you could just identify the recruiter and assistant profiles and then just check the "Read only" check box for just the specific profiles. But I'm going to back out of that. And then the other option that was specified was that you could go into the permission sets inside of Setup or create a new permission set and just name it whatever. And here I will go a little further on this for sake of demonstration. So I've named a new permission set, and this is where we'd set the object settings, because remember that it's only through the object settings and the permission set that you can get to the actual object and then set the field level security. So we could edit Contacts, and we wouldn't have to worry about credit rights because we'd leave their credentials as they are on their profile. We don't care about whether they can see, read, edit, delete, or whatever. We need them to be able to at least see the salary field. Now, I don't think we have a "salary" field out of the box. We would need to have previously created a salary custom field. But let's say in this example that instead of needing to make this visible, these profiles for the salary field, which doesn't exist in our instance, will open up read-only access for the title field on the Contact record. not nearly as sensitive information, but it'll do for demonstration purposes. So at the field level, we're opening up read access for the title of this profile and clicking Save. And then we could go into their profile, which would have been "Recruiters and Assistance." But let me go into the profiles for our own instance, the one that we've been dealing with, the ContractManager, and then we can check and see if they have the appropriate object settings for the Contact object. And so we see that they have recreate, edit, and delete rights for their credit rates on the Contact object. So we know that they can access the actual object and the records themselves. Then, for those records that they have access to, they will only have access to the field that we specified in the field. So now the other question that relates to where we're at currently in this course is question number three, and it says that an administrator has been asked to create a new field called Region Code on the Opportunity Object. And this field should only be visible to users with the outside Sales Manager and System Administrator profiles and editable by users with the System Administrator and Manager profiles. How should the administrator ensure this field is accessible to only these users? Now when they don't specify how many answers to select, it's inferred that you're only to select one. So, how would you handle this as an administrator? Options are either to edit the field level security on the region code field for these three profiles, to create a new record type and page layout for the opportunity object for these three profiles, or to edit the role hierarchy and move the outside sales and manager roles lower in the hierarchy. Or D would be to create a new page layout for the Opportunity Object for these three profiles. Now, looking at some of these, some of them may kind of work, but they aren't the best approach. You could create a new page layout for the opportunity object for these three profiles, but then at the page layout level—I showed this earlier—you could set something to read only. But the problem is that that's not the best approach because that's not addressing things at the profile level. And so someone could, if they have only access through the page layout, still potentially add it potentially.So for example, if we were to create a new page layout and do a page layout assignment for those three profiles, that doesn't lock down this region code field, this new field called region code, to the other profiles. And so other individuals, even though that region codefilled may not be in their page layout, may be able to get to that through a list view or through a tab, for example. There may be ways that they can get to that field. And so we want to lock this down and restrict it at the profile level. So it says that this field should only be visible to users with the outside sales manager and system administrator profiles. So it says that this field should be visible, which would be read only for outside sales manager and system administrator profiles, and then read and edited by the editor for the system administrator and manager profiles. So you would want to edit the field-level security on the region code field on the Opportunity Object for those three profiles. So two of the profiles would have read and edit ability. And really, the system administrator profile has read, edit, and delete permissions; it has a view on and can modify all data, so I wouldn't really worry about that one. However, for the manager profile, you should ensure that you set, read, and edit access to the region code field in the object settings for Opportunity Fill Level Security. And then for outside sales, you do the same, but only have it selected as read and not edit. You would not want to create a new recordtype and page layout for those three profiles because that is overkill and doesn't lock down access to that field for the other profiles. And you always want to avoid creating new record types until it's an absolute must. There are a lot of reasons for that that go beyond the scope of this lesson. We'll go into that later and then edit the role hierarchy, moving the outside sales and manager roles lower in the hierarchy. That is hinting at restricting access to the records, but that doesn't dictate field-level security. So they're throwing this in here, and they do this a lot. Salesforce does this a lot, to see if you understand the difference between profiles and roles and what they control, and to remember the roles in the role hierarchy. Control access to individual records or the records you have access to, and open up access vertically through granting access using hierarchies. And we'll get into that more later as well. However, the profiles are where you control the credit rates as well as the fill level security. And so on this one, the answer would be, Let's look at that. That's question three. And just to confirm, it does take some time to think about those scenarios and keep these different scenario-based questions in mind. As we progress further and more deeply into security access, we're getting to the point of traversing up that upside-down pyramid that we looked at earlier as far as the security model of Salesforce. And we're next going to be looking at worldwide defaults.

8. Setting Organization-Wide Defaults

So now let's look at org-wide defaults. You can also access organization-wide defaults by going to your organization's Sharing settings. So select Sharing Settings, and then at the top of the screen it shows the organization-wide default results for your organization. And then there are a few things to note here. One is that out of the box in our free Salesforce account, there are no custom objects. These are all standard objects. And for the standard objects, if this checkbox for granting access using hierarchies is checked, you cannot uncheck it. Now you can either grant access using hierarchies or not for custom objects. We'll be creating some custom objects later. But I wanted to note that as an important point. And then as well, some of these objects have a designation of being controlled by parents. So for example, Contact is controlled by Parent, which would be the account object. It is the parent of contact records. And so whatever the Orgwide default is setfor, account will dictate what the. org-wide defaults for contact and many other things If I were to go in and try and set accounts to private—and I've had to work in instances where we've done that before, where we're hiding account records from everyone other than the owner—I wanted to show you some of the implications of setting the account access to private. When the account access is set to private, it also states that case access must be private. If we close that, another warning says that if the case sharing mode is private, each case queue must have at least one member. If we close that and click Save, and whenever you change the sharing settings on.org WideDefaults, the sharing rules must be recalculated based on the new defaults, the sharing rules must be recalculated. and this can require some significant time. If you have a lot of records in your organisation, I'm going to go ahead and select Okay. So, what are the implications of making accounts private? One thing that I should note is that one or more sharing operations have been initiated, as this warning here indicates. And so while it's waiting for this process to complete, you cannot be creating any new sharing rules for any of the impacted objects. And I wanted to show you how far-reaching some of this impact is whenever you set up or change the account. For example, there are several objects that are impacted here. So not only is the account impacted, but some of the other related objects will be getting into the control of parents here shortly in the next lesson. But I wanted to show you that not only is an account impacted, but also opportunity and case sharing rules. And so we can refresh, and we also receive an email whenever those calculations are done, but I'm going to refresh my browser, and we'll see this go away because there should be adequate time for that to have occurred. all those recalculations to happen. Now we have accounts set to private, and contracts is another corresponding object that is set to private. Those kinds of hand-in-hand contracts are kind of unusual object.And so we'll look at the object map model and schema and some of these relationships here soon. However, some of those other affected objects or cases are now private, as are opportunities. And so, a couple of other things to note are that you will always have either equal or more restrictive default external access when compared to internal access. It does not make sense that the internal users have private settings for the account object, but then for external users, such as those using the community, it wouldn't make sense for them to have read and write abilities. and so external users such as those in a partner customer community, for example, will have the same or more restrictive access rights than the internal users. On another note, you'll notice different variations with these different designations on these objects, such as private, which we set for account of course, and then controlled by parent, which we'll discuss in the next lesson. But then as well, you notice here with lead records we have public read, write, and transfer access to the lead object. Also, cases out of the box have public read, write, and transfer abilities. So if you think about the nature of those that are working leads or working cases, oftentimes they need the ability to transfer a problem case or a hot lead, for example, over to someone else. And so that gives you access to being able to transfer those records to someone else. And so the organization-wide defaults are the base-level security setting, and they control access to other users' records. Now, even though the account has been set to private, if a user creates an account record, they will have access to that record, even though the account's worldwide default is set to private. So arguably, defaults control the access to or dictate the access to other users' data. I believe that this is actually spelled out here: these settings specify the level of access your users have to each other's data. And so now let's talk next about "controlled by parents" and what exactly that means. I'll see you in the next lesson.

9. Controlled by Parent

This "Controlled by Parent" default sharing setting that you find on some of these objects, such as Contact Order and Asset, I wanted to show you more details on that particular setting. We'll also look at this. Soap API Developer Guy is here momentarily. But if you go to the organisation wide defaults help link, it takes you to this organisation wide sharing defaults help article. There's some more information or examples on the Controlled by Parent settings here. Let me search for "controlled." And there are a few instances here in the Help article. This doesn't really relate. This one's here. When the default access for Contacts is controlled by a parent and you increase the default access for accounts, opportunities, or cases, the changes take effect after recalculation is run. So let's see what we can edit and change on the contact object. So we could change this to private, public read only, or public read and write? So on the contact record, when we try and change that, you see this warning. There's this conflict between these two objects because they are connected through a relationship. So the contact access must be private or controlled by a parent. When the account access is set to private, we cannot have the contact object have greater openness in its security model than the parent account. The Parent account is set to private, so we need to have Contact set to private or controlled by parents. So it's blocking us from being able to change it. So even though that selection is there, we cannot do public read-only or public read Write.We can only set control to "Parent or Guardian" to match the account setting. So let me show you what I'm talking about here insofar as these objects are concerned with the relationship that they're in. I'll link to this as well, down below, as a reference. And this is the Sales Objects ERD diagram. And this is inside the SOAP API Developer Guide. There's this handy section for data modelling inside this guide, and it breaks it down by sales objects and a lot of other different types of objects such as support objects. As an advanced administrator, you may be curious about not only the relationships between objects, but also where the Sales cloud begins and ends and where the Service cloud begins and ends. And so, here are the supporting objects. These are typical objects you'll deal with in a Service Cloud instance compared to the Sales Cloud, which would be the Sales Object. Some of these recur across the different clouds, such as Account, which would be a good example. But we were trying to set the contact object to public read Write.And you notice a connection between the contact and the account. As you can see, if we set this object to Public read/write, And that would infer that we need to open up further access to the Account object as well. You can see the relationship standing between two objects by going into the interface. I'm on the Account object; let me go in and edit this object and view the fields on the Account object. The fields and relationships And this is VIA, the object manager. You will not see a contact field because contact is the child and account is the parent. So what you need to do is go to Object Manager and look at the Contact object. And here is where, under fields and relationships, you will see a relationship up to the Account object, and it is a Lookup relationship. and so I wanted to look at that and verify that it is indeed a lookup. In addition to the contact, other things associated with the account include orders and orders, which are located between accounts and contracts. Let's look at the relationship on the order object then and see if this is a master detail or a look-up relationship. So if I go back into the object manager, let's go into the order object, and then fill out the relationship lookup for Account, which is also a lookup field. So in this diagram, you can see the far-reaching impact of setting the Account object to private because it does impact these other objects that have a relationship with an Account, such as Order. And then, through order, there are also contracts that are affected. And if we go back to our org-wide settings here, if you remember, there was an account and then also a contract tied into it, and that's because order resides between account and contract. So let me go into the object manager for contract, and I'll show you that, and then build some relationships on contract, and then the contract. I actually missed this one here. So it has a direct lookup relationship from contract up to account, and it also has this indirect relationship through order. As a result, order functions almost as a joint object between account and contract. But there's also this lookup relationship here. And so depending on where your object resides in the schema, it can potentially have some far-reaching effects. You need to be familiar with the relationships between these objects. Whenever you're setting the work by defaults, you're determining what's controlled by the parent, and if you run afoul of that, then you will be warned. And so for example, opportunity is another object that has a relationship, and it has a lookup relationship with account as well with Account.And so if we try and open up further access, it warns us once again that with the account access set to private, operating access must be private as well. Another way that you can visually view all this is through the schema builder. I'm not going to say anything about the changes I've been making to the ORG-wide defaults, but the schema builder is a good way and a little more interactive and better at denoting what's a lookup relationship versus a master detail versus this diagram here. I'm not seeing a lot of consistency between some of these relationships and don't see a legend here. And some of this is conflicting as to what is master detail versus look up.So I do recommend, if you need a more in-depth view of the relationship between objects, that you go into the schema builder to help you understand this whole "controlled by parent" concept. And we can clear all of these objects on the canvas here in the schema builder, and then we can selectively select those that we want to see. So I'm doing accounts, contacts, contracts, opportunities, and cases. I'm trying to think of what else might be related. All right, so then you can kind of zoom out some to get oriented here and figure out where you're at. Let me drag my view and drag some of these together. So one thing about the schema builder is that unfortunately you can't print these out. You can do screen captures, and once you get these things arranged to where it makes sense, you can see through this colour coding that the blue lines are lookup relationships and the red lines are master details, and you can hover over these and see these different relationships. So for example, most everything that we're looking at here is driven off of this account. Now there's a master detail relationship; it's a hierarchical relationship from account to account. These other relationships are lookup relationships, from account-to-contract to case-to-contact, etc. For when we talk about controlled by parent, if you are setting control by parent on an object such as a contract, case, contact, or opportunity, just know that the parent to these objects is the account. As a result, whatever the organisational default is set on the account will be inherited by these other objects due to the parent setting. When we go into the sharing settings inside of setup, we set the default sharing settings for what are known as "our." org-wide defaults. Now that we've covered controlled by parent and become familiar with the ERD diagram for sales objects in the SoapAPI Developer Guide, we've also looked at the schema builder to figure out some of these relationships and what is inferred or what controlled by parent means. Now we're going to start getting into the next level of the security model; we've gone from organization-wide defaults now to getting into the role hierarchy, which we will do in the next eleven.

10. Roles and the Role Hierarchy

up to a higher level of the salesforce security model from the.org wide defaults found in the sharing settings screen here and start talking about the role hierarchy. And that does relate to these checkmarks for this grant of access using hierarchy. Now, remember that these are checked by default and cannot be unchecked for any standard objects or custom objects. You can turn this on or off, and we'll be creating custom objects later. But the way that Salesforce is intended to work is to grant access or open up access to records for those that are above you in the role hierarchy. A common concept of this would be that a manager has access to the records of those that report to him or her. So their subordinates' records roll up to the next level in the role hierarchy. And so let's go into role hierarchies here, and you should have some understanding of roles in the role hierarchy. If you pass the admin exam, when you get into the role hierarchy here and if you expand all to show the expanded role hierarchy and what's available in a free Sophistic account, it's a pretty robust role hierarchy, and you can view this in a tree view or an assorted list view from the drop-down menu here, or show it in a list view. And this indents things to show a little bit more of the nested nature of a role hierarchy. So it really just depends on what you prefer. I do recommend that if you ever make changes to a role hierarchy, you copy this before you make any changes so you can refer back to it because it is really easy to get confused and to move things around and then have a lot of unintended consequences whenever you change who reports to whom. One way that you can see who is assigned to which roles in the role hierarchy is to go to the user screen and go to the user's ListView. So if we go to Manage Users here and set it up and go to the All Users List view, it lists out the profile that each user is assigned to and then any role that anyone happens to be assigned to. Now remember, you can only be assigned one role, just like you can only be assigned one profile. You do not have to assign a user to a role, although it is a good idea to do so. It isn't really necessary for the system administrator profile because you have "view all" and "modify all" access rights, which override the role hierarchy designations; you can basically see everything. So it doesn't really matter that you assign yourself a role. Previously, I had assigned this western sales team role to John Doeto. So let's look at that and bear in mind that he is the only user in our instance that is assigned a role. If I go back to roles and this is under users once again, these are all user-related things, meaning these are things that they can be assigned to. And this Western sales team is at the bottom. So, if we click Assign, we'll see our current assigned user, Jim Doe. If we want to assign other users, we can do so by selecting them and moving them over, then clicking Save. And so we have this Western Sales Team, and let's say that we wanted to assign someone to this Director of Direct Sales. This is the person to whom those on the Western Cells team would report directly. So let's click "Assign Here" and let's assign myself. Or actually, it doesn't really make sense to sign myself because I'm an admin. Let's assign the integration user and click "Save." So the integration user is now higher up in the role hierarchy, and any records that JimDoe, the owner of this integration user, has access to would also have access to, within reason. Because one thing to note is that although, in theory, a user may have access to records for their subordinates, their profile may prevent them from having access to certain records. So for example, for this integration user, let's see what profile they have. So, let's take a look at this integration user record that came with the free account and put it in this director role in the role hierarchy, and see what kind of object settings they have. So it looks like they have read and viewed all of the standard objects. And so let's look at it now, or point our attention to this read, and view all object permissions on the account's object. Now remember, we set the orgwide default on the account object to private, and then for this particular profile that this Analytics Cloud user has, the permissions on accounts are read and view all. They don't reside in the role hierarchy in a management position, and they have people reporting underneath them. So remember, if we look at the role hierarchy, that this is the director of direct sales, that is where the analytics integration user is, this integration user, and then below him in the hierarchy resides Jim Doe and then also the security user. Now this is setting us up pretty nicely for contrasting profiles and roles. But before we're ready to do that, I want to look at the profile settings for Jim Dough on the account. So let's go to the object settings. So Jim Doe has read access on the account object. So in order to be able to tell the difference more fully between profiles and roles, I want to get it set up so we can login as other users so we can test the visibility and look at when we make changes to the organization-wide defaults. What that impact is based on user profiles and roles, and why logging in as other users is NASA's next step.

Pay a fraction of the cost to study with Exam-Labs Certified Advanced Administrator certification video training course. Passing the certification exams have never been easier. With the complete self-paced exam prep solution including Certified Advanced Administrator certification video training course, practice test questions and answers, exam practice test questions and study guide, you have nothing to worry about for your next certification exam.

Hide