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

Security and Access : Object Level Access

1. Section Overview

Well done. Well done. Congratulations on completing the previous sections. Let's move ahead with our next section on security and access. Let's take a quick look at the exam guide. We are at the Salesforce trailhead. We are the Advanced Administrator exam guide. And now we'll move on to the section Security and Access. As you see here, the weight is 20%.

So this is the section with the most weight among all the sections out here: 20%. Meaning, in your exam, you can expect around 12 to 13 questions of the total 60 questions from this section, and the description is given below. So they discuss the sharing model controlled by parent grant access by hierarchies profiles, sharing rules, community security settings, field and record level access, field level security, record types, territory management regarding permission sets, custom profiles, delegated administration, and so on. I've covered almost everything in the Security and Access section, as well as additional concepts. Pay a lot more attention to this particular section. This holds the maximum weight. So you can expect a greater number of questions from this section. Good luck.

2. Security and Access – Overview

security and access. Security is activated the moment a user logs into the application. So what is security? Security defines everything, and users can access it, it's as simple as that. What can a user do with that? What is it that he cannot do? So all of that is defined by security restrictions. So as soon as we log into the application—or any user for that matter—what is it that he can do? What is all that he cannot do? Say, for example, that as a user I can see all these tabs, right?

And when I click here, I see my profiles, my settings, and all these things. So what are all the options a user can have? And when I look here, what are all the apps that I can access? What are all the options that I'll have in my setup here? And what are all the tabs that I can see? Even if I click on a tab, what are all the records that I can see? And even if I click on a record, what are all the fees that I can see? Literally every single thing that we see in salesforce.org is controlled by security.

So what is all that a user can access? that is defined by security. And in real time, we very well understand that different users should have different levels of access, right? Team managers should be able to access some sort of permissions, whereas team members should have a different level of access. CEOs should have a different level of access, CFOs should have a different level of access, and sales reps should have a different level of access. So all these factors are basically defined by their roles, their day-to-day activities, and their teams. Sales teams, like marketing teams, would have varying levels of access based on a variety of factors.

So different users have different levels of access to any.org, and that is all defined by security. So we define security in salesforce.org in such a way that appropriate users should have appropriate access to Salesforce. The salesforce security model basically has three major levels of access. The first is object-level access. The second is record-level access, and the third is field-level access. First is the object-level access. Object-level access is basically baseline access.

There is nothing that can grant more access than object-level access. And in Salesforce, object-level access is defined by profiles and permission sets. Next is record-level access. So, once the object-level access is defined, say, a user has access to a specific object, the record-level access follows. So I have gotten access to an object, but what are all the records that I can see? Can I see all the records, or can I see only some of the records? So here comes record-level access.

So, while both users A and B have access to an object, this does not imply that they see all of its records. No, user A might have access to some records, and user B might have access to a different set of records. So that is defined by record-level access. And the third level is a free level of access. So there is one particular record in an object, say, for example, a student record. So both user A and user B got access to the student record. However, we can still impose restrictions stating that student A can see all the fields. However, student B can only see some of the fields of that record. So that is a free level of access. In Salesforce, field-level access is controlled by a concept called "field-level security." So this is the overall picture of the salesforce security model: object-level access, record-level access, and field-level access. We configure all these in such a way that appropriate users get access to their appropriate data and components. And in the coming sessions, let's discuss in detail each one of these.

3. Managing Profiles

Profiles. In the previous session, we discussed the various levels of access that we have in Salesforce, starting from object-level access to record-level access to field-level access. So now that we have an overall understanding of the Salesforce security model, it's time for us to jump into each one of them and understand what is there in this video. Let's understand more about first-object level access, especially profiles. So what is a profile?

Profiles basically define how users access objects and data and what they can do within the application. as simple as that. When a user logs into the application, what can they access and what can they do? So as a user, when I log into the application, what is all that I see? What are all the tabs that I see? And what are all the tabs that I see here? What are all the objects that I can access? And when we say objects, what are the record types within the objects that I can access? Everything is defined in a profile. Similarly, what are all the apps that I have here, and which are all the apps that I can access? And are there any restrictions on the login hours? Are there any restrictions on the login IP ranges? What are all the apex classes that I can access? What are all the VisualForce pages that I can see?

So all these are defined in profiles. So profiles provide baseline access. There is nothing that can provide more access than profiles. And for a user in Salesforce, every user is associated with a profile, and every user is associated with only one profile. A user can't have multiple profiles assigned to them; they can have only one profile assigned to them. And like the other components in Salesforce, we have both standard profiles and custom profiles. As the name implies, standard profiles exist by default, whereas custom profiles are created by the user. Now let's go to the UI and take a look at the profiles. Go to setup and look for profiles. We manage user profiles. So these are all the standard profiles that Salesforce provides by default. And here we have the option of creating a new profile. And when we create a new profile, we create new custom profiles. And we should also understand when to use standard profiles and when to use custom profiles. So standard profiles are what we use whenever our requirements match a standard profile. This, say, system administrator profile is generally standard, and we do not update it in any way. Assume that this identity user has a typical user profile.

And for this profile, as you can see, the page layouts are defined, the field-level security is defined, the tab settings are defined, and the record settings are all defined. With the administrator's permissions, what are all the objects that a user can access? Everything is already predefined, and when our requirements match this profile, we use the standard profile. If not, then we create a new custom profile. And in real time, creating custom profiles is pretty common. We do create custom profiles in every Salesforce.org instance. Now let's take a look at the standard profile, which is the system administrator profile. So all system administrators will have this particular profile. As you can see, the System Administrator Profile basically controls all of these.

It controls all the console settings that we have, all the console layouts that we can access, and all the page layouts that we can access. What is the field-level security that we have? The customer app settings, which include all of the apps we have access to, are essentially tab settings. And what is the level of access that we have for tabs, default on, default off, or hidden? The record type settings What is the default record type for a profile? The administrative permissions, the various administrative permissions that we have, the various general user permissions that we have, and the standard object permissions So when it comes to standard object permissions, it lists all the objects, both the standard objects and the custom objects here. And what is the level of access a particular user has to the objects? As a result, this is commonly referred to as "Crude Permissions." As a system administrator, you can create, read, update, and delete the basic Crud permissions.

All objects, both standard and custom, are accessible to system administrators. We can, however, modify it when creating custom profiles based on the requirement. Assume that marketing users require access to specific objects. The sales user needs to have access to another set of objects. A different set of objects, or even the objects themselves, may be assigned to a sales representative. Different users will have different permissions. Some users can only read the records; some users can read and create records; and some users should also be given permission to edit and delete the records.

So based on the users' profiles, the Crud permissions also differ. And that is for the standard objects, and this is for the custom objects. And you can see here that these are all the custom objects that we created in our app and in the other settings as well. The password policies, including how long they can expire, as well as the login hours and IP ranges. Login hours mean that only during specific login hours will a user be able to access the application and the login IP ranges. If you want to have any restrictions on the login IP ranges, we can define them accordingly. What are the Apex class VisualForce pages?

Pretty much the majority of the components that we access are all defined in profiles. So the profile defines the baseline access. A single profile is assigned to each user. Let's take a quick look at the users. This being a developer's edition, we have only two users. We can create a maximum of two users. We have not created our second user; we just have the default user that we have. And here in my case, I have created one user for myself. And as you can see, there is only one profile assigned to me. So when I hit edit, you can see here that the profile is system administrator, and here we can see that we can't update it because there is only one single user and there has to be a system administrator in the arc.

So that is the reason. But otherwise, when we create a second user, we should be able to modify the profile, and we basically want to come here to see that one user can have only one profile assigned to we create a So now that we have an understanding of profiles, let's see a quick comparison between Salesforce standard profiles and custom profiles, and let's also quickly create a custom profile and understand it. So these are all the standard Salesforce profiles that we have, and the one that we just discussed is the system administrator profile.

Let's consider any other standard profile, say, the standard user profile. This is a different standard profile that is available in Salesforce by default. And when you try to edit the standard profile, we see that the custom app settings can be modified, the tab settings can be modified, and the administrative permissions are not all present for this user. We can see that many of the checkboxes for the general user permissions are unchecked, and even in the general user permissions, not all of the permissions are available; only a few permissions are available, and we also do not have access to modify the standard profile, right? We only have access to modify certain attributes, that is, the tabs and the apps.

But otherwise, we do not have access to modify any other attribute. The standard object permissions are all pretty standard, and we can't modify them or some of the other session settings or the password policy settings. So these are the few attributes that we can modify for the standard profile. So this applies to pretty much any standard component in Salesforce. Standard components are generally not 100% editable. We will be able to edit only a few of the attributes of the standard components. So the same thing applies to standard profiles. Also, we will not be able to change all the attributes of a standard profile; only a few attributes can be updated. So in that scenario, when we need a custom profile that is very different from the standard profile that is already existing in Salesforce, we create a custom profile based on our requirements.

Say, for example, that for this field of education, we have already created some custom objects to learn more about the objects and the application. So for that, we created some custom objects. So, if salesforce.org is used in education, perhaps we can create custom profiles for instructors and separate profiles for students. We can create custom profiles like that. And if it's sales and marketing, we'd make sales profiles, marketing profiles, separate profiles for field sales managers, and possibly separate profiles for sales reps. We might have separate profiles for the marketing team like that. Based on the industry, we create separate profiles for separate requirements. So now let's quickly create a custom profile. Hit the "new profile" button, and as you can see, we can clone any existing profile. So let me try to clone the system administrator profile and the profile name.

You can give it as per the requirement; I have given it as a sales system administrSo our first custom profile is created, which is the Sales profile, and it has the same level of access, that is, page layouts, console settings, field level security, custom app settings, tab settings, and record type settings. So all the access that we have for the system administrator, we have for this profile as well. Basically, we cloned that profile. So now we can edit this profile, and we can update the permissions accordingly. You can see the custom app settings are editable, the tab settings are editable, and the administrative permissions are entirely editable, right? But this was not the case for standard profiles. These attributes were not editable in standard profiles; they were all read-only by the general user permissions, whereas the standard object permissions in almost all custom profiles are 100% editable.

We can modify the permissions as per our requirements. So just to give you one single example, what I'm going to do is just take off the permissions that we have for the extracurricular object, save the profile, and then create a new user and assign this custom profile to that user. So to create a new user, go to users, hit the "new user" button, fill in the details here, and while selecting the profile, I have selected the sales profile. The sales profile is a custom profile that we just created. So, once you've completed all of the perfect now our user two is created, which is mapped to the profile, the sales profile that we just created. Now let's log into the application using this user two. Now I have logged into the application as user two. We can see here that these are all the standard tabs that are available by default, and this user, user Two, has the customer profile and the sales profile that we created. And in order for that profile to understand the difference, we did not grant this user access to the object extracurriculars. So we should not be able to access the extracurricular object. So for that, what we can do is click on the tabs here.

We should be able to see all the other custom objects that we created, for example, instructors and students. These are all the custom objects that we created. And we should also be able to see courses, other custom objects, and departments. But we can't see the extracurricular objects because we didn't grant access to this profile to see the extracurricular objects. However, keep in mind that we only changed one attribute in a profile. Profile has a large number of attributes that you can modify, which we discussed initially, starting from the page layouts, the record types, the login hours, the IP ranges, the apexclass visual force pages, along with the standard object permissions, custom object permissions, and the administrative permissions.

So, in the profile of this object, we have a number of attributes that we can control, and this is one of them. So, if we just wanted to see the difference between creating a custom profile and granting or revoking access to a specific component, I would be happy to show you. That is why we revoked access to one object that is extracurricular. And when we log in to the application as that user with a custom profile, we are not able to access the extracurricular object because this profile does not have access to the extracurricular object. Not only this user, but all other users with the custom sales profile that we created will be unable to view the extracurricular object. That is why we say that profiles define basic access. Profiles define all the objects and data that a user can access when they log into the application.

4. Profiles – Considerations

In the previous session, we discussed profiles. What are profiles? How do we create profiles? Why do we actually create profiles? What is the significance of having profiles and all these things? But as a senior administrator, we should explore the concept of "little more." So now let's discuss some of the key considerations that we need to keep in mind while we use profiles. So profiles, as we know, define how users access objects and what they can and cannot do within the application. So everything is defined in a profile, and we know profiles are tagged to users, so every user has a profile tagged to them. Profiles: we have both standard profiles and customer profiles.

Standard profiles, as the name implies, are available by default when we purchase Salesforce CRM; there are approximately 30 to 35 standard profiles available. Standard profiles are similar to any other standard Salesforce component in that we cannot create them, we can only modify them (with very few exceptions), and we cannot delete them. Custom profiles, on the other hand, are, as the name suggests, created from scratch. We can create, modify, and delete custom profiles. And as they are custom profiles, they are customizable, meaning we can update the attributes we can attribute. meaning in the profiles. It means the permissions that are basically granted as part of that profile.

We can delete customer profiles. However, we should note that we cache custom profiles only when there are no users assigned to that profile. So remove all the user assignments, and then we can delete custom profiles. So when standard profiles are already available, why do we create custom profiles? As far as we know, it is not possible to change all of the attributes of a standard profile. We can modify only certain attributes. In that case, if we have a requirement wherein we need to modify the other attributes, if we want to grant more access than is available in a standard profile, Then we create our own custom profile based on our business requirements, and creating custom profiles is a very common scenario in real time. In projects, we have custom profiles created and we use custom profiles as well, and here is a tip that, as senior admins, we need to know that while creating a custom profile, we know that profiles cannot be created directly; we can only clone an existing standard profile.

Thus, we can create a new custom profile and we have already discussed how to create a custom profile, so when we clone a standard profile, we can basically pick any standard profile that is available and we can clone that standard profile and we can update the permissions accordingly. However, while choosing the standard profile, it is always a better option that we choose a read-only profile because a read-only profile has only the minimum permissions, so it will be easy for us to modify it. Basically, it makes a job easier, and that's it. Say, for example, that the system administrator profile is a standard profile.

However, it appears to have all of the permissions. So modifying all the permissions would make the job a little hard. So choose the read-only profile and then copy it, then create a custom profile that makes the work a little easier. So when we talk about these standard profiles, we know that when we purchase a sale for CRM, we get standard profiles. We have some standard profiles, like about 30 standard profiles we have. However, as senior administrators, if not all, we should be familiar with some of the standard profiles. These are some of the standard profiles that I have listed, which are very commonly used in real-time projects. So, at the very least, we should have an idea of what these ninth and standard profiles do and where they apply. So the standard profiles that we need to have an idea about are the system admin, the standard platform user, the standard user partner user marketing user contract manager, the chatter free user chatter, and the external user solution manager.

At the very least, we should have a basic understanding of these standard profiles. So if we go to our application, all the profiles are listed under "manage users' profiles." We can see all the profiles here, and I can see 37 profiles out there. Among those, a few are custom, like 44 profiles or custom profiles. So, like, there are about 33 standard profiles we have. So, if not all, at least a few of these standard profiles should be familiar to us. So the first profile that we are going to discuss is a system administrator profile. So when we created the developer Edition.org account, automatically a user was created, and we logged in using that user. This user is tagged to the system admin profile because there should be at least one person with system admin rights. So automatically, that system administrator profile is stacked for us. And we have been using the system administrator profile, as the name implies.

System administrators have 100% access to Salesforce. They are allowed to configure and customise the entire application. So every single permission, all the access rights, are given to the system administrator. So when we talk about these standard profiles, I highly recommend that you go to each one and see what all the various options are and what all the various permissions are that are given to each profile. Just see, like, what are all the apps' permissions that they have. Tab permissions, record types, administrator permissions—almost all permissions are available to system administrators. Take a general look at it and get a high-level understanding of the standard profiles. That would be the best way to learn about these standard profiles. The next is the standard platform user.

So let's go back to profiles and go to the standard platform user. As the name says, it is a platform user, and the user licences the Salesforce platform. Essentially, these users are permitted to use all custom apps developed as part of the.org, or they may be installed from App Exchange; whichever method they choose, these users can access those custom apps, as well as the main functionality of the salesforce platform as a standard platform user. So again, as I mentioned, take a look at the various permissions that this profile has. Take a look at all the password policies, the login hours, and the Apex classes, which are all the sections that they have access to and which are all the sections that they do not have access to. Just take a look at that. Moving on to the standard user profile, this is actually a very common standard profile that we use in real time. Essentially, they can create and edit the majority of most types of records with this standard user profile.

They can run reports and they can view how organisations are set up for campaigns; they can view the campaigns, but they cannot manage them as such. Similarly, they can create solutions; however, they cannot review solutions. They can edit personal quotas, and they can also override a forecast. These are some of the important features of this standard user interface. And as I mentioned, this is a common profile that we use in real time. Partner User: A partner user, as the name implies, is a user who is only allowed to log in from a partner portal. So basically, users and partner users access the Partner Portal. And this profile we assign to those partner portal users—marketing users—because, as the name says, this profile we assign to all the people in the marketing team. And these users manage campaigns.

They import leads, and they create letterheads and HTML email templates. They can manage your public documents, and they can also update the campaign history. Essentially, they can function as a standard user with additional marketing capabilities. This is another of the common, standard profiles that we use in real time. Next are contract manager users. With this profile, they are allowed to basically create and edit contracts. They work on contracts so they can create contracts, edit contracts, activate contracts, and approve contracts. They can also delete contracts, but as long as they are not activated, they cannot delete activated contracts. But for inactive contracts, they can delete them. Again, they can edit personal quotas and override forecasts.

Next come the chatter-free user and the chatter-external user. As the name says, these are for chat users. The chatter-free users They can log into chatter and use the standard chatter features such as people, profile groups, files, and so on, which are all available with the chatter free user license. However, as an external chatter user, they can also log in and join groups to which they have been invited. Also, however, they can interact only with the members of those groups, and for this, they need the Chatter external user license. Next is the Solution Manager, a standard profile. And as the name says, solution managers work with solutions. So users with this profile can review and publish solutions; they can also act as standard users.

They have pretty similar functionality to the standard user. And finally, there is the read-only user. This read-only standard profile is also one of the most common ones we have in production in real time. These read-only users, as the name says, can only read data; they can only view the records, but they cannot edit them. So these are all some of the very common, standard profiles that we use in real time. So as a senior administrator, it is highly recommended for us to have at least a high level of understanding about these profiles. So the best way to learn about them is to go to each and every profile in salesforce.org and see what various permissions they have. That would be a good learning experience.

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