Pass Salesforce ADM-201 Exam in First Attempt Guaranteed!

All Salesforce ADM-201 certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the ADM-201 Administration Essentials for New Admins practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

Salesforce Security

1. Learning Objectives

This subject is really quite cool because I quite like getting into the kind of security of salesforce, but it can get really complicated because it is a really flexible security model. So you can really kind of get into the nitty gritty of exactly who has access to what records within Salesforce or what features within Salesforce. So this section is all about security, and what we're going to be going through is how to troubleshoot common users' access and visibility issues within Salesforce. We're going to look at the core organisational security options that you have. Now, I think of this as how people log into Salesforce, but it doesn't go into the specifics of what records they have access to. Then we go under the various permissions and profile controls that you have within permissions and profiles. We're going to describe the capabilities of the sharing model so you can understand how records are shared between users. And then finally, we're going to understand the appropriate use of using a custom profile. So let's dive in.

2. Salesforce Security Overview

Okay, so now we're going to talk about Salesforce security. Now I'm going to quickly give you an overview of security, and then we're going to kind of dive in and go into a bit more depth on each of the areas so you can understand it for the exam. So first up are the core.org security settings. Now, I think of this as like the fundamental security of salesforce.org. It doesn't really talk about records or users. It's more about, okay, if a user creates a password, what's the complexity of that password, or which IP addresses do you want to whitelist? the kind of fundamental stuff that isn't record specific. Then we get into record access.

And salesforce's record permissions are very much owner-based. So based on the owner of the record, they have access or don't have access. And people in the hierarchy above them, the role hierarchy, could potentially have access. And there's manual sharing or criteria-based sharing, as well as Apex sharing and account teams and things like that. But for the exam, we can actually discount three of these, which are the account sales teams, territory management, and Apex sharing, because they're not needed for the exam. But it's good to know that they're there if you need them or if you want to kind of dive in and learn a bit more about it. So first, I just want to kind of go through and say how all these different security features kind of fit together and in what order as well. Now, the very first one is the default.org wide access. And I think of this as a kind of fundamental record security access that's driven by objects.

So, for example, if I was on the accounts object, I have three possible security permissions I can set on the ORG wide defaults for the account object, and that's public read/write, public read, and private. and this governs the rest of the security. But there is one fundamental thing you need to understand. Once you've let the genie out of the bottle and given somebody access, you can't lock the access down. You have to start with the most permissive, the most secure type of object, and give access rather than restricting access to records, if that makes sense. So, for example, with the ORG-wide defaults, if I set my accounts to, for example, public read/write, there are no features in Salesforce that allow me to restrict the access to records in there because basically everybody's got read/write access.

So I can't say, except for this record. So if I wanted even just one record to be private, what I'd need to do is basically make that object private and then open up all the records to everybody except for that one record. rather than doing it the other way around. making the object public to everybody and shutting down access, because you can't do that in Salesforce. So you've just got to remember how that works. So even if you want one record to be private, you have to set the whole object to private and then open up access to everyone except for that record. And there are a couple of different ways you can do that.

The first way is through the role hierarchy. Now, you can think of this as an organisational tree, say, and all the records that I own based on the ownership field on the record, my boss can see as well, because he's higher up in the role hierarchy. Then we have sharing rules. Now, these are the kinds of rules that you can setup to say, "Well, this set of records can be seen if the fields are set like this on the record," or "I want to share all these records with those who are in the HR department with a different department." And this is where all the rules kind of come in. And then we've got manual sharing, which is kind of like record-by-record sharing access. So I can say that I actually want to share my one record with this person over here, or a group of people, but it's kind of on a record-by-record basis. Okay, that's a really high level view, and it might sound really complicated at the moment, but we'll go through some examples and we'll dig into this in a lot more detail going.

3. Organizational Security Settings

Okay, so what we want to take a look at now is the organisational security settings, and these are some of the fundamental settings within Salesforce for your organization's security. Now, as we said earlier in the overview of security, this kind of security sits on the outside of record-based security. So we have the record access functionality and features within Salesforce to allow us to open up access to records, which is our default global record ownership hierarchy, et cetera. But then we've got these kinds of fundamental.org security settings that manage password lengths and stuff like that and cascade across all your users and your whole organization.

So let's take a look at these settings. So here I am in my salesforce.org account. Now all I need to do is search for "security," and you can see under "Security controls" that these are essentially at the core and a lot of the core security settings for Salesforce are in them. Now I'm going to highlight a couple of these because they are relevant for the exam, but if we dive in here, the first one is the health checks. And this is what I recommend everybody doing in their Salesforce.org. The health check is essentially about finding risks in your Salesforce configuration and your current security setup. Because Salesforce is so flexible in how you configure the security, it can be that you've actually reduced the security of your salesforce.org based on the settings within it. So I highly recommend everybody kind of going into the health check and trying this out on their Salesforce.org and checking what values they have set on different security settings and if they need to be changed.

So for example, here it's going to be a score of 74% for My.org on my security health check, and it's highlighted some high-risk, medium-risk, and low-risk settings. So you can see here that we've got a high risk of having the maximum number of invalid login attempts. Currently, I have it set to 10, but Salesforce recommends changing this to be three. So every time somebody tries to log into Salesforce after three login attempts, it's going to lock mySalesforce.org, and at the moment it's at ten. So they kind of recommend three.

Then we got some other kinds of settings, so some clickjack protection around visual force pages. Currently it's disabled in My.org, so I can get that enabled. And Salesforce is saying these are the most high-risk vulnerabilities currently in your salesforce.org, so you really should change them. Then we have medium-risk settings, such as password complexity, length, and things like this. Again, check them out, and you can change them if necessary. Make sure you kind of try it in a sandbox first, just in case, especially around VisualForce pages and things like that. That's kind of more code-related, so you kind of test it across some of your visual force pages to make sure enabling this doesn't actually break anything. But 99 times out of 1099 times out of 100, it will be fine. So go with it. Okay, so the next one on the list is password policies.

I click in here. Now this is like the fundamental permissions around passwords within Salesforce. So you can see here that the password expiration is set to 90 days. After every 90 days, your users will have to reset their enforced password history. So you can say how many passwords and previous passwords are remembered. We've got minimum password lengths. Then you can see the level of complexity surrounding the passwords. And if you noticed in the health check, it actually said that I should include special characters to kind of make my password complexity a bit better. Then we have password requirements and lockout. So you can actually lock users out if there are multiple invalid password attempts. I can say that the lockout time is 15 minutes, or it could be 30 minutes, 16 minutes, or forever.

And it's up to the admin to reset and unlock that account before the user can then log in again. So depending on what your security is, you can change that. And actually, my health check said that I should reduce this to three. So that's what I'm going to do. And that's essentially it for the password policies. Next, I want to show you the session settings. The session settings are all around when a user logs in: where was the session initiated from? and for how long have they been using—or not using—that session? So the first option is a session timeout. So this is saying that once I log in, if the user doesn't do anything for 2 hours, it's going to automatically log them out. And I'm saying force the logout on session timeout. Now, 2 hours may be a bit much for some people. I like to keep it around 15 or 30 minutes, just to stop potential other users from using Salesforce if they walk away from their desks and things like that. But again, it's down to your particular circumstance. Then we have IP locking.

So an IP address is essentially a unique identifier for where the user is logging in from. So I can lock the sessions to the IP address from which they originated. which basically means that if somebody tries to log in somewhere else, I can basically kick out the first person. So there can only be one person logged in at any one time, which is good for security. If we scroll down a bit more, we get to the clickjack protection. So those are the protections that Salesforce said were high-risk. So I'm going to enable these as well. and that's essentially it for them. And so that's essentially it for the password controls. So I'm going to say that next we have network access. Network access allows you to whitelist IP ranges. Now an IP range is, as I said earlier, a kind of almost uniquely identifiable address from where a user is logging into Salesforce on the Internet. And Salesforce has the security that if somebody's logging in from an unknown location that you don't know about, Salesforce will ask them a challenge question to get them logged in.

So typically, this will be an email into their inbox saying, "Can you type in this code when the user logs in to verify that they're actually logging in from a trusted location?" or if you're using two-factor authentication or a mobile app to log your users in. It may be that when the user logs in, they have to tap in the code that appears on their phone using the Salesforce Authenticator app. but with the trusted IP ranges. What you can do is basically say that for these types of IPS messages, don't allow or stop salesforce from sending them to the user. I just want the users to log in. They type in their username and password, and they log in straight away. They don't get this. Or you've got to tap in a code, or you've got to receive an email with the code in it, before you can log in. So that's what network access does. It doesn't stop users from coming into SalesForce. and that we'll talk about a little later when we talk about profiles.

So network access is just whitelisting, or basically giving permission for these specific IP ranges. They don't need to activate their computers if they're logging in from a different location. But it has a weird name: "network access," which you'd think is okay if it only allowed access from these specific IP addresses. It's not that. So be aware that this is only for activating computers and not for limiting access to these IP ranges. And you can actually do that in profiles, but that's something separate. So next we have activations. Now activations are essentially what I've just mentioned before, where you're having to activate your connections, your computer's connections. And you can see here that I've actually activated my account on a number of different IP ranges and the date of when it was authenticated and if the challenge response was completed. So this is tapping this code in, and these are the login IP ranges.

And then below, we've got the browser activated. So you can see here which browsers have been activated and are allowing access to Salesforce. So there's the activating of the browser as well as activating the IP address or the location where they're logging in. So now we have session management. Now session management is the live sessions. So this is who's logged in right now into Salesforce. And you can see that I'm logged in twice. I'm logged out using a UI session type, which is a user interface, and also using a content session type as well. But if I wanted to forcefully remove these users from my salesforce.org, I can select that, click Remove, and it basically kills their connection and they have to re-log in again. So now we have login access policies. Now, these are quite cool, and I would actually enable this if you want, if your security within your company allows, but this allows administrators to log in as any users in Salesforce, which can be really handy for testing new logic that you've done when you enable this.

When you go to manage users, you get this little login option on the left hand side of the user, and that means you can log in as that user without needing their password and you can perform actions as the user within salesforce.org. Now you've just got to be aware this could actually open up issues as well because then you're allowing any administrator to log in as somebody else and potentially change an alter record. But this option does come with a little bit of a sting in the tail, and that is, if the administrator logs in as a user, you get an audit trail showing that the administrator has logged in as that user, but you can't see what the administrator has done. If you run the audits on the user, it will look like the user has performed those actions, such as creating records, updating records, or things like that. So it may be that the audit trail kind of breaks at that point, and actually, that's not compliant with your company's security rules. So just be aware if you do enable that, and if you don't care about that, that's all fine, but otherwise be careful if you switch that on.

We also have the organisational support, and if users allow it in this circumstance, salesforce support can log in to help them out in a certain scenario. Or you can just switch it to administrators only. So only administrators can allow Salesforce access to salesforce.org. Now, if you've got other packages installed in your.org, you may get a list in here as well to allow those companies to log in to check why the app isn't working or not, but it's not an automatic thing. You do have to select it from your preferences and say, "Hey, I want to allow access to Salesforce support for a certain amount of time." So switching this on doesn't mean that salesforce can login now; you still have to kind of grant them a specific amount of time access into your salesforce.org. Next, we have to set up the audit trail. Now this is actually quite cool; it shows all the changes that have happened in your setup menu, essentially. So you can see here that I've actually changed my session settings, so I enabled that quick chat protection, as you probably saw.

And you can actually download six months' worth of audit trails in here, so you can see exactly who's made those changes in your setup, which can be rather handy when things start breaking because somebody's put a validation rule in or somebody has made a change and you want to understand who's made that change. Next we have the option to expire passwords, which can be really handy if you want to expire everybody's password so that the next time they log in, they'll be asked for a new password. So this could potentially be because, you know, there's been an accidental release of passwords into the Internet or something, or potential issues have occurred, and you just want to expire everybody's passwords, get everybody to put a fresh one in, and then they can kind of carry on using Salesforce.

So next we have remote site settings. So remote site settings are essentially saying that if there's a process that has been invoked from within Salesforce, which websites are permitted for Salesforce to contact? So in here, you can see that ApexDevNet.com has permission if there could be a bit of ApexCode or it could be a workflow process or something within Salesforce, and it needs access to this domain. And therefore, the only way for it to contact that site on the Internet is by adding a remote site within this one. But this is usually the domain of the developer rather than the administrator. But it's a nice check to see if anybody has opened up security in your arg and maybe put a bit of dodgy code or something that could be pushing data out to a website that you're just unfamiliar with. So it's a good list to take a look at.

Next, we have platform encryption, which can be found right here at the bottom here. Now, there are two different types of encryption. We've had a look at encrypted fields, but this can actually encrypt selected fields within Salesforce. Now you just need to be at least a little aware of it and know there are two different types of security. This platform encryption, which is kind of a new platform, the "shield" security, and also the standard fields within Salesforce that you can make encrypted So when you're creating a field, you'll see there's a field type called encrypted fields. That's the classic security or classic encryption. And this is platform encryption, which is, basically, more heavyweight, basically. Finally, I just want to show you login histories, which aren't actually in the security controls. So if we search for login history and click in here, here, we can see who's been logging in from where, from which location, what browser they're using, and what type of login it is. So you can see here. I've logged into the application, and I'm on a Safari Mac browser, which is correct, and I've logged in from the United Kingdom. And that's me, totally.

But you can see here, in the one below, that I've actually logged in, and it looks like it's come from the United States. But this is a remote login, and I've already logged into the Salesforce User Groups website. So you can see here that actually I've kind of connected to the Salesforce user group website, which has asked me to authenticate into my salesforce.org. And now it's kind of just put a little message saying, "Hey, I've logged into the Salesforce user groups using my login." You can see it here. I've had some invalid password attempts. So I've gotten my password wrong three times now because I've gotten my password wrong three times because we changed the settings. Potentially, I could have locked my account out at that point and had to wait 15 minutes or however long we set before I could log in again. And sure enough, I then logged in successfully, which is all well and good, but it's always nice to see how many times people get their password wrong or if you're getting lots of invalid password attempts now. It is quite difficult to see this information sometimes because it is such a massive list.

You can download it as Excel and kind of load it up and do stats and stuff within Excel, which has more information, which is quite useful. But there's another new feature within Salesforce called "event monitoring," which you can find in the setup menu here. And this goes into a lot more detail and helps you do login forensics and report a lot better on that information. But that is essentially it for the security settings. You just need to understand that this is kind of the core setting within Salesforce. It doesn't affect users' specific access or recorders' specific access. It's that core password level for logging into Salesforce, and you just need to understand some of the features, such as password complexity, that health check, and some of the things you can do within security settings. If you have any questions on this, be sure to ask them in the comments, and I'll get back to you. Otherwise, I'll see you in the next video.

4. Organizational Wide Defaults

Defaults now. So this is like the fundamental layer that sets the security perimeter around your objects in Salesforce. Without having this set correctly, you won't be able to secure your records or share them with different people within your organization. Though if we look at our controlling of the record access, you can see that there's this layer right at the bottom, which is the organisation-wide defaults. And here we can say that if we give an object public read and write access, there's no more security permissions that we can put on that object to kind of restrict access to people because essentially the genie is already out of the bottle. It's a public rewrite, and it's going to be made publicly available to everybody. There's nothing you can do from now on.

So even if there's just one record that you want to secure, you have to change that model. If you only wanted one record to be seen by maybe one person in your organization, you'd have to set that object to private and then share all the records with everybody in the organisation with the exception of that one record. And then set up another rule to share that one record with that other specific person. So it's very important to understand how the security model works in Salesforce. You have to make everything private and then open up Access and set everything to public read. That means everybody's got read access, and then open up the edit access. So that is basically the fundamental information you need to understand. So let's take a look at the organisation wide defaults and how we can customise that in Salesforce. So here I am in my setup, and all I need to do is search for sharing, and then I get these sharing settings options.

I go into here, and here are my organization-wide defaults, and this sets the default permissions for my objects. Now there's a couple of different types. We've got public read, public write, and transfer. So essentially, this is the lead object, and it's basically saying absolutely everybody has read and write access to all records within that, and they can also transfer ownership of that access. Then we have accounts and contracts. They're public; everybody can see them, and everybody can read and write to them. But we can't reduce that security with this setting currently in place. We can't say these specific people can't see specific records, but if we carry on down, we've got campaigns, and we've got users.

And you'll also see there are some other options, like control by parent, which essentially says that there's a master detail relationship between this object and another one. So if I scroll down to the bottom, you can see my custom objects of invoice and invoice product. The invoice product is controlled by parent, and in this case, it's being controlled by invoice because there's a master detail relationship between the invoice and the invoice product objects. And as we know, if it's a master detail relationship, the security cascades down from the parent object. So essentially, we can't change these settings because they're being driven by another object's security settings. And the invoice is controlled by parent, which in this case, when I set this invoice object up, is controlled by the account.

So if I wanted to change the security permissions upon this invoice, I'd have to break that master detail relationship. or put the security at the account level. So let's see if we can customise some of these. If I click Edit, we can see that we've got Campaign and User. So at the moment, every user in Salesforce can see all other users. Now maybe you've got Global Company, and you don't want that to go across borders or something like that.

And so we can change this to private. Now this is making this object private to the world. And now we can slowly open it up. And the same way with campaigns, we can change this to "public read only," which means that all campaigns within this campaign's object will be read only. So I click save on that, and there we go. It's saved. And it's now going to do this calculation just to recalculate all the security rules, which I'll receive via email once it's completed, and then I'll know that all those new security rules I set in here have kind of been sorted out by Salesforce.

Salesforce ADM-201 practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass ADM-201 Administration Essentials for New Admins certification exam dumps & practice test questions and answers are to help students.