The Complete Course from ExamCollection industry leading experts to help you prepare and provides the full 360 solution for self prep including Certified Advanced Administrator Certification Video Training Course, Practice Test Questions and Answers, Study Guide & Exam Dumps.

Security and Access

16. Teams Access

Discuss team access. This is the next layer in the sharing architecture of Salesforce where access becomes even wider. So if we go into setup and searchfor teams, you'll notice that there's a fewdifferent places that teams appear and teams areavailable on the account opportunity and case objects. As a result, an account team is frequently referred to as a sales team, and an opportunity team is frequently referred to as a sales team as well. So you can go into an account team and see that there's also more information on what these teams are and why they exist with these different team settings that you have to enable in your.org. And one thing to note is that account teamsare available in Southwest Lightning in addition to SalesforceClassic and also in the mobile app. And that did behind Account Team isyou can create an account team. Let me check the box that says Account Teams are enabled and then click Save. In this way, you can have a common set of people on a team. And I've worked in instances where perhaps there's more than one owner of an account, and this is one way to handle this instead of Salesforce because each record is either owned by an account or a queue, for example. But in some instances you may have multiple account owners, and so you need to enable account teams in order to allow for that. Or oftentimes there may be with an account, an accountowner, there may be a project manager, there may bea project coordinator that works in conjunction with the projectmanager, there may be a business analyst, all of thoseindividuals may be part of an account team. And you can have multiple account teams as well. And so you can select as well which page layouts you would like to add the account team to, and this will appear as a related list. So I'm going to select all of the different account page layouts and then add them to the user's customised related list, so that if the user has customised the related list, when they click Save, it will also add this account team related list to their page layouts. Now that you've got the account team enabled and you've added to the page layout the related list, you can get into team roles and replace team roles. And also, you can disable account teams by clicking this link here. But let's look at team roles to seeif there's any available OutoftheBox once they're enabled. And there are, and these are some of the common ones that you'll find on the account team, such as an account manager, and then you may have on an account a channel manager, an executive sponsor, a lead qualifier, etc. A sales manager, sales rep. You can also deactivate some of these. You can rename or delete them, and you can reorder the order that these appear in. And before we get too deep into the account teams, Consider opportunity teams. and once again we need to enable team selling. So these are different ways of opening up access to records through team settings. So we did enable account teams. We've not set up any of our account teams yet, but let's enable team selling by clicking Save. And let's look at this in a similar experience. We need to add the Opportunity Team related list to these different page layouts and then add it to the users' customised related lists and click Save. As a result, the disabled team selling would be the only option for opportunity team settings. So if you want to turn that off, you just check that, and then just select Disable Team Selling. The final team designation would be case teams. And you notice before I even click on Case Teams,there's a lot more options now in the setup menu,now that we've enabled Account Teams and Opportunity Teams. Now for the case teams. We can select case team roles. And with Case Teams, you can select or create roles. And so a "Case Team" would be those that are working together as a team to help resolve a case. So oftentimes, in an environment like a call centre, there may be those that fulfil certain roles. Let's look at the pre-defined case teams, and there are none. Let's see if there's any help on this page to give us some good examples. Yeah, so there aren't any examples of any common Case Team roles, but let's go back into Case Team roles then. Let's just create one, and we'll just say that this is Let's say that we're working on cases where we're having to deal with government entities. And one of the case rules we may need is government liaison. For example, this would be a specialist in your support organisation that has experience dealing with government entities. You can then set their case access to private read only or read and write. You can also make them visible in the portal. We'll get more into customer portals, communities, and case management later. But I wanted to show you how to at least create a team role for a Case Team member. And so for some of these other settings around account teams, for example, and getting into these team roles Remember, we've got several here out of the box, and I will show you where these come into play now on an actual account record. And they will also look at an opportunity as it relates to teams as well. And these are different teams, I might add. An account team is different than an opportunity team. So if I go into one of the accounts that I own and go into the related tab, which is open by default, we should see the Account Team here. And we do; we can add team members manually or add a default team. Let's click on "Add Default Team." We have not set up a default account team. So let's add team members. All right, so I'm going to create a small team here and I'm going to add Jim Doe, and this just pops up automatically. Or you can search; these are some recently used user records, and we'll put him in the team role of presales consultant. Account access will give him rewrite, case access will give rewrite as well, and opportunity access will also grant rewrite. And this would be for any opportunities that belong to this account. For example, we've given him rewrites across the board. So we're giving the presales consultant read-write access to the account case and opportunity. And then, for another user that is an active user integration user, we give him the team role of lead qualifier. And let's say that would just give him read-only access to the account for read only.Or, for example, make a case private so he doesn't have access to cases belonging to this account, and then read and write on opportunity before clicking Save. Now we've got an account team. So let's say that in this particular account team, you work with the same people over and over in the same roles, and you wanted to set them up as a default account team. You set that up in your advanced user details. And once that's done, you could then Add default team," and it would automatically add these people to these team roles on the account of whatever record you're working in. But since I don't have that setup, it shows this error here. It says I can't add the default team; ask the record owner to set up a default account team and then try again. And so the way that you set up the default account team is you go into your own advanced user details, and I am in my advanced user details. Now, the way to get to this—there are a few different ways you can get here—is if you hover over this icon in the top right, or if you click on it, it opens up this window here.So then you click Settings, and it takes you to your personal information. So then you just click on advance user details, and then you can see here the default account team. So clicking on that takes you to the default account team relayed list; click Add, and here's where you can specify your default account team members. and these would be people that you normally work with. You'd also select to automatically add my default account team to accounts that I create or accounts that are transferred to me and also update account teams with these members. So we could specify that we want to add Jim Doe here, and just like the other way, we could specify their account opportunity for case access. And I don't remember what I said previously on that one account. We're just going to do this. So I say presales consultant, and then I believe his integration user, and we'll just give him the defaults and call him a sales representative. Click save. And so now that I've set my default account team, I can go into an account—let me just go into a different account that doesn't have an account team designated already. Let's say, let me pull up one that I've not dealt with; scroll down to the related list for the Account team. And because it is one of my accounts, it has added that default account team to all of my accounts, it appears. I wasn't sure if I'd have to click "Add default team" or not. Let me try one more account really briefly just to verify that pyramid construction, another one of my accounts, and the Account Team have been added. So that is dynamic and does update all of my accounts with the default account team because I set that to automatically happen. And so let's go into Jim's account and see if we can add a default team. And so here's one point of reference: it has to be the record owner who sets up a default account team because if it's not owned by you and it's owned by someone else, if you're trying to add a default team, it needs to be their default team and not yours. So one point of distinction: if we go into opportunities, let's look at the related list on the opportunity, and we'll look at one that we ownhere to look at one of your owned opportunities.And if we look at the related lists on the right, the related list for opportunities differs from the accounts on the left, the related list for opportunities on the right, inconsistent interface. You could either add opportunity team members or an account team so that the parent account team members are added to this opportunity. So you can, with the click of a button, make the account team members also part of the sales team, which is known as the opportunity team. You can also manually add Opportunity Team Members if you need to add more team members. And you select first the role, then the user, and then the opportunity to access it. So now I've added an executive sponsor. This shows just two, but I added a third person. Let me click View All, and this will refresh. Oh, okay. Other than that, the right integration user was already on there. So I didn't add an additional user, I just changed the member's role. And so if I try to add a default team, I don't have a default opportunity team set. So once again, you can do that by going to your settings and then going into advanced user details. And then in addition to the default account team, there's also a default opportunity team. That's another related list where I can specify my default sales team and automatically add my default opportunity team to my opportunities that I create or open opportunities that are transferred to me and update Open Opportunity Teams with these team members. This was the corresponding checkbox on the account team members, which is what caused my existing accounts to be updated because I checked the update account teams with these members. So it's kind of the same concept here. On opportunity, teams I'm just going to select Jim Doe as part of my sales team and click Save, and you get the idea there. Account Teams. The Accounts Opportunity Team is also known as Sales Teams, and you can have that update all of your opportunities by checking those checkboxes that we looked at. And let's look at another sales opportunity team here. We've got our Jim Doe account manager on the team. So, that is team access. Remember, that's across accounts, opportunities, as well as cases. And so the bottom line is: a team is a group of users that work together on an account, a sales opportunity, or a case. And then you can also specify access levels for each team member that has access to that record. And so one thing that I mentioned previously had to do with record ownership and how all records have either one owner or are owned by a queue. So I think it's important to mention it before we return to this diagram. and especially before we tackle this very deep subject of territory hierarchy. I feel it's important and wise that we talk about record ownership in general and cues.Because record ownership and ownership by cues is another piece of this puzzle as we look at the sharing architecture that is not really drawn out here and is kind of inferred with the users down here at the bottom, we will not include it in this diagram. But just keeping in mind that records are owned by the user or queue, So I want to look at queues and record ownership in the next lesson.

17. Record Ownership and Queues

Back to our sharing architecture Remember that all records in SalesForce need to be owned by either a user or a queue. And a queue works much like an individual user, but it allows groups of users to manage a shared workload more effectively. Queues are commonly found in Salesforce applications such as case management and working leads. Those are common places that you will find queues, and that enables users to all work within, for instance, a queue of cases or a queue of leads and work through a shared list view and then pull cases or leads off of that list view and claim ownership and then work that lead or work that case. And then the goal of individuals inside those queues is to try to work through those records in order to get the queue down to a manageable amount, and ideally down to zero. So to create a queue, you first click the new button, and then we're going to just stick with a common use case and we're going to create a case queue by selecting that particular object. You can select a lot of other objects here, and it is important to realise that you can have a queue for not only cases and or leads, but also all of these other objects and also custom objects as well. So I'm just going to call this the case queue. So in thinking through a good scenario, I'm going to go ahead and call this tier two. So the idea behind this, and I'm kind of rethinking this as I go, is that for this particular case queue that we're creating, this will be for users that are more part of an escalation process and are at a higher level. And so it's not the initial entry point for all cases, but those that are set at a Tier 2 level of resolution. And you can also specify sending an email to the queue members as well. And so then, as far as the members of the queue are concerned, you can specify or select individual users or roles and subordinates or just roles, or, as well, public groups. Now we'll talk about public groups in the next lesson, and we'll actually create a public group so that we have more to work with than just all internal users. And so let's dive into creating a public group. And you see this link over here under Users; right by the queues, there happens to be this link for public groups. I feel like now is a good point to right-click and open this in a new tab in order to create a new public group. And we'll do that in the next lesson, and we'll complete this process of also creating this queue.

18. Public Groups

So now, rather than dealing with a public group of all internal users, let's create a new public group. So I previously right-clicked on Public Groups here and setup and opened that in a new tab, which is here. and you can select to create a new public group. And a public group can contain members of other public groups or those in certain roles or subordinates or individual users. And so let's look at the role options here. And since we're looking at a customer support type of role or public group need, let's just say that anyone in the role of customer support international and/or North America will be in this public group. Then there's anyone who provides installation and repair services. So let's give a label to this public group. And just for sake of demonstration, I'm just going to call this Tier Two as well, or Tier Two Support, and click Save. But before I do that, let me show you this. Checkmark this public group that Grant access using hierarchies." So this is another place that this particular designation appears to be known as "Grant Access." Hierarchies are used within a public group. And when that's checked, any records shared with users in this group are also shared with users higher in the role hierarchy. So anyone in these roles and anyone above them will have access to those records will be shared.I'm going to click save. Now this is a public group that we want to then be able to select whenever we're creating a queue. Now I'm in the middle of creating this queue, so I don't think unless I refresh the screen and start over, I'm going to be able to find this public group. But let me try it. I'll look for Tier 2 in the public groups and select "Find it isn't there." So I'm going to select just an individual user, Jim Doe, and then click save. And then I'll go back in and edit this queue and add additional users by using the public group. So I'm going to click Edit on this queue and revisit my public group and search for public groups here. And now I have my Tier 2 support team. And so one thing to mention is something that's often confused: the concept of groups versus teams in salesforce. Now a public group is this disparate set of users, people, roles, and subordinates, other group members, or groups that can be grouped together. And then you can use that group to do things such as assign membership instead of queueing. For example, that is vastly different than a team. We saw previously that we set up an account team, an opportunity team, and a case team. As an example, the account team granted team members access to not only the account but also the opportunity. And those can be set, and you can set default teams, et cetera. That is very different from the public group's usability. And so, hopefully, that makes sense to you as an advanced administrator here. And there are a lot of pieces to this puzzle when it comes to security and data access. So, as we circle back around, we'd like to save our updates to this queue. And now we've created a tier-two queue, and the supported objects in this queue are the case objects. And so, what happens, or is implied to happen, whenever you create a queue—which is kind of cool—actually is unless I am a member of this queue, which I don't believe I am. Yeah, so let me edit this and add myself as a queue member. And so then once I'm a member of this queue, a related list is created for me for whatever objects are impacted. So let me go into cases and see if I can find a related list called "tier two." And this will be the list view for that queue. And those are the cases that that queue actually owns. So I'm going into the case tab via the all items list in the app launcher. And so now if I click the drop-down menu here, I now have, because I am a member of the queue, a tier-two list view, and this is the view that the queue members would be working from for any cases that are inside of the tier-two queue; there are no cases that are owned by this queue. So what you could do is go into all-open cases and reassign some of these cases to the queue. And a common use case for this is, let's say, we're getting towards the end of the day and there are three cases of mine that are still open, and I'm the case owner and I'm getting ready to leave. And if we're working inside a 24/7/365-day support centre and there's a second shift coming in and they're getting ready to work cases, I could reassign these cases to someone else. And so, for example, I'm not able to go from this list view and mass reassign these, but I can click the drop-down menu and select Change Owner individually, and you can search for people and also queues. You should be able to, and it doesn't look like I can change the case owner. Let me try and search for "QS." Okay, here it is. I'm spacing out there a little bit. So I need to change the drop-down designation for search from people to queues. I believe that being able to mass-reassign all cases from a list view and lightning to a queue, as well as search for people and queues at the same time, would be extremely useful. But at least we have some ability to locate the queues and change the ownership. You could send a notification email as well. So I'm submitting this. So, at the end of the day, I'm wanting to clear my queue of my open cases. And these are all open cases. You usually have a list view of my cases, and this is probably more of what you'd be working from. That's all of my cases, even those that are closed. So I'm going to just go back to all open cases, not deal with that mess, and let's reassign these other two open cases. and it does not persist. If memory serves, in the context of looking for cues, I believe you can master reassign from classic. And if this changes, let me know. Or if you know a way to mastery-assign from Lightning and I'm just spacing out on this, just let me know. Through the magic of hopefully faster editing, this won't be quite as painful for you to go through. All right, so now I've mastery assigned thosethree cases to the tier two queue. And so now if I go into the tier-two list view, then we should see those three cases. What's significant about this is that all queue members, if there are multiple users, can go in and see which cases are being worked and which are still in the queue, with the end goal of keeping this as close to zero as possible. Then we'd probably sort by priority to see which are high or medium, and work on the case with the highest priority in the queue. And then they could just change owner and takeownership and just change it back to themselves. And that, in essence, is referred to as taking things off the queue. Now. I live in the real world, and I'm a realist. And so I realised that oftentimes people inside queues will cherry pick, and they'll look at the different cases and see which one will probably be the easiest to deal with. or if they have to make an outbound call. The one who is most likely not at home and can log in activity because that is how they are measured and possibly compensated. And so what they would do realistically is view the details of the case and decide which one they want to cherry pick, and then select to take ownership by clicking change owner and assigning it to themselves, for example. And that, in essence, takes the case off the queue, and they own it. And the idea behind that is to avoid other workers inside the queue from working on the same case and avoiding conflict. And then your Tier Two list view updates accordingly. So, once again, records have to be owned by a user or a queue. And queues are a group of users that work on a shared workload and are very useful. They also introduce a listview whenever you create a queue. And also, queues are supported across a multitude of objects, but the common use cases would be dealing with leads or case records. And then also, in addition to the work that we did around queues, that also led us down the path of seeing the need for creating a public group, and we also discussed the difference between a group and a team as well. And while we have covered a lot of ground in the sharing architecture between users and now queue profiles and permissionsets.org, wide default role hierarchy sharing rules, manual sharing, team access, and so on, some things have not been displayed. In addition to queues and users, we also have public groups, and how that relates, compares, and contrasts with teams But before we dive into territory hierarchy, there are a few other topics related to security that are not represented in this diagram either. and some functionality that Salesforce provides for you to check the health of your security by running the health check, and I'll show you how to do that in the next lesson.

19. Running the Health Check

Let's run some health checks. Y'all, did I mention I am from Nashville? All right, so the health check is a feature in the setup menu, and it gives you a Salesforce baseline standard score and determines how well your organisation meets Salesforce's security standards, and so it very quickly gives me this kind of mediocre score of 70%. Your score may vary, and there are some high-risk security settings. Some of these are critical, and those are listed toward the top, followed by warnings and then compliant things down below and then the medium-risk security settings, and this shows as far as compliance. These are things that are checked, and it's finding that you are in compliance with what are considered best practises for security, but then critical things are shown, and then it says what your value is and what the standard value. what the desired value is. So for example, one of these medium-risk security settings is that you could set a setting to require a minimum one-day password lifetime to prevent users from resetting their password multiple times on the same day. So we could enable that by clicking Edit in the Actions column, and that will take you to where you need to go to address that shortcoming in your security. and then you could go and refigure your score and see how that's improved, and here's the check box for requiring a minimum one-day password lifetime. For example, if I click Save, I can go back into the health check, and that has given me three more percentage points. The goal here, at this point in time in this course, is not for you to attain a perfect score. Its primary purpose is to make you aware of the security health check's existence and then to begin to understand some of the high-risk security settings, at least as far as Salesforce is concerned, and to become aware of what these settings are, as well as what is considered high level or critical. What are some borderline things that would be warnings and then other things that are considered compliant? This will help you get a holistic view of some of the security settings, and this is an important piece of security and access. You may be asked about this on the exam, so I wanted to make you aware of the healthcheck and some of the usability of that. The purpose of it and how you can fix some of these settings to bring your salesforce.org into better compliance, and then here at the bottom of the low-risk security settings, how this works as well, and some of these are informational, but if you address these issues depending on the severity and the low, medium or high-risk setting that will impact your score more greatly, and so I do not encourage you to just randomly enable all of these settings because it may have some dire consequences that you're unaware of at this point. So we're not going to make other changes. I do encourage you not to go in and enable or bring all this to compliance at this point, but just to leave things as they are. And especially don't be making changes in a workplace environment because oftentimes there are settings that organisations strive to improve upon to improve their score, but there are certain things that they've built that prevent them from doing so. And if you were to enable some of these things, it may have some dire consequences or lock users out or break some integrations and have some serious cascading effects. So as always, you want to do this under the auspices of a sound change management process being in place and always testing things out in a sandbox environment before doing this in production, of course, as well. All right, so as we back out of this healthsearch term for the health check and get back into security, in addition to the health check, you see some of the other things that we've worked with before and some that we've not touched on. Some of these are highlighted in the exam guide, and I'll speak to them momentarily, such as delegated administration. Also, we'll be talking about community security settings as well. That is another thing that is not specifically spelled out in this diagram, but it's important and also noted on the exam guide. But then there's also this inauspicious link here called the Account Owner Report. And I want to talk about that briefly in the next lesson.

20. Account Owner Report

Behind this, we have our sharing model, or.org widedefault, on the account object set to private. The issue with this is that it leads to a large number of duplicate account records because sales reps and other people who are just trying to make a living are unable to see what accounts are in salesforce. And so then they go and they call on Sony, for example, and they create a new account record called Sony. And then everyone else under the sun who works within the organisation is also trying to close a deal with Sony or GE or Phillips or whomever—some sort of conglomerate. and this leads to a lot of duplicate accounts. So, if we allow all users to run the accountowner report and click Save, users will be able to see which accounts are in their organization. So in order to access the account owner report, you have to go into Salesforce Classic. I had to pause recording because I was assuming that this report would be available in Lightning by now. But as yet another instance of something that's not supported in Lightning quite yet, So the use case would be if you have a private security model on the account object and you want to at least give users the ability to view what accounts are in your instance and who owns those accounts, they would have to switch over to Classic and know to run this account owner report. As far as usability goes, it's not the greatest. Now, if you know of a way to run this report from your Lightning experience, please let me know in the comments. Otherwise, enjoy the lack of usability of Lightning Experience and return to Classic. So the account owner report shows all accounts in your organisation along with the account owners. So it's a way of at least opening up a little bit of visibility so that users know what accounts there are and who owns them. So if you just leave the default and click "run," So let me try and log in as a different user and see what the experience is like for Jim Doe, for example. So, going into Jim's record, I can login as him from Classic here if I go into the user detail and select Login. All right, so now I'm logged in as Jim Doe in Salesforce. Classic. You see the designation here: the login is Jim Doe. In this black bar here, I'm going to go to the accounts tab that takes me to the accounts home page inside of Classic. And then here under reports is the account owner's report. if I run the report here. So I'm thinking he has full access to all these because he's above me in the role hierarchy, now that I think about it. So I'm not going to go too crazy over this. Let me change my role. So I've got to log out as Jim Doe. Let me edit, and I'm just going to remove my role altogether. Say none specified, click save, and then I'll go back into Jim Doe, login as him, go to accounts, go to account owners, and run the report. Oh, alright, so he has access because he's on the account team. I'm a moron. There you go, duh. Alright. So I forgot. So even though I removed my role from the role hierarchy and this is the real world, this is just keeping it real, and this is how you troubleshoot: you test things out, and then your hypothesis gets blown out of the water, and it's like, "Why does he still have access to this account?" And then you remember, Oh, he's part of my default account team. So not to be too obtuse, but I'm going to keep going because any good advanced administrator doesn't know when to quit and give up; they just keep on going. So I'm going to go back into my user record, and this is how through repetition you begin to learn, right? That's part of my master plan: the strategic mistakes that I make on purpose. This is not just oversight or forgetfulness; this is, to use the term I used previously, visionary. So where's my default account team? So here we go. I am going to get rid of Jim Doe from my default account team. So clicking Delete will delete the member not from Salesforce.org but from my default account team. You can also remove him from all the account teams on my accounts. So I'm clicking delete. So now I've effectively removed JimDoe from my default account team. So now let's try this yet again, shall we? Let's go in. At this point, I don't really care if Jim can see all the details of all the accounts known to man on our.org, but that kind of attitude will get you fired. So we're going to be thorough. We're going to be advanced administrators. Let's do this. Accounts, I'm logged in as JimDoe's account owner, and I'm running the report. Run it, Jim. Run it. All right, so the account owner report does display a little bit of information beyond just the owner of the account and the name of the account. It'll also reveal other details around the account site, if that is prevalent, or the owner role. And then, as well, the created date, the last modified date, and the account ID. But if you notice if you click on one of these accounts, I'm logged in as Jim Doe. This is something he shouldn't have access to, and he has insufficient privileges. So the idea behind the account owner report is to give users the ability to run the report from the accounts tab before they introduce a new account by creating a new account to see if it already exists in their organization, and then they can do an operator to see if it does. For instance. If they're considering opening an account for Sony, for example, They can see if Sony already exists or not before creating a new account record. And once again this is only available in classicand it is only available as well once it'senabled and also only available if you have accountsset to private at the orgwide default. So now that we've survived the myriad of issues with the account owner report and challenges therein, let's look at some other security settings as we logout as Jim Doe, and before we get into territory hierarchy, we also need to look at community security settings, and we'll do that next.