Pass Salesforce Admin Certification Exams in First Attempt Guaranteed!

All Salesforce Salesforce Admin certification exam dumps, study guide, training courses are prepared by industry experts. Salesforce Salesforce Admin certification practice test questions and answers, exam dumps, study guide and training courses help candidates to study and pass hassle-free!

Salesforce Security

5. Record Ownership

This is where Salesforce really sets itself apart with its record ownership security model. Now a lot of the security you'll see from now on revolves around who owns the record and how it will be shared with other people. This distinguishes Salesforce from other companies that develop CRM solutions. So the best way is to show you how it works. So here I am in my salesforce.org account. I've just created an object called Private Records. Now, for this object, I've given it access to myself and another user within salesforce.org, but I've set the organisational-wide defaults to Private, the most restrictive security you can put on an object. I've now granted myself access to this object via the profiles.

So that basically allows me to create records. So I'm now going to create a record. This object has only one field, which is called the text field. But just so you can see that I'm creating the field, So I'm just going to say Francis's Record, and you can see here that the owner is me because I'm creating this record and I click Save. Now that I've created this record within the Private Records, this essentially means that if I'm a standard user, I can see all my records, but I can't see anybody else's records because I'm not the owner of those records. But if I dive in and log in as somebody else, I have a user called Joe Blogs who again has access to the private record through his profile, and I'm going to just log in, and here I am on the private records, and I'm going to create a record as well.

This time I'm going to call it Joe's Record and click save. So now if I go to the front tab of Records and click Go to search all records in this object; I can only see the record that I've just created. I can't find. So Joe's record, he can only see his; he can't see the other record that I created, which was the PR-5 record. And if I try and search for the record, it just doesn't exist. No matches were found. And this is one of the key things about Salesforce. It's all about ownership. Now if I click into this record, you can see that I can change the ownership of this record.

So the moment it's linked to me, if I click Change, I then have the option of either assigning it to another user or assigning it to a partner or customer portal users. This is all about salesforce communities, so we'll get to that later. However, these are the three that can be altered using custom objects. So I'm going to just change it to me and see what happens the moment I change it. Pop the box up and there I am. The moment I change it to me, the record disappears. And now I can't see it anymore. And if I click on the view, it literally looks like it's just vanished because I've changed that ownership from Joe Blogs to Francis Pinder, and now only the Francis Pinder user can see it.

Now, if you're an administrator, of course you'll be able to see all records within this object, but as a standard user, it's now vanished. But it also applies to other objects as well, but they work a little bit differently. So if we look in, say, the leads, let's search for a lead and just grab a lead from there. All I have to do now is go to the ownership section and click "Change." You can see that there is a Q here now. And this can be really powerful because I can basically add multiple people to a queue and assign the queue to this lead record. And this essentially allows me to assign a lot of people to this record as an owner. But the moment somebody then says, "I'm going to work on this lead and change the ownership to themselves," nobody else can see the record. So that's what queues can be used for.

Now, queues really only apply to leads and cases. So you can create a case queue, or multiple case queues, or multiple lead queues, but you don't have it on custom objects. So it's just something to be aware of. Now, for the exam, you need to understand that when you make an object private and a user creates a record there, they are the owner of that record. And that assumes there are no other sharing rules, a role hierarchy, or anything else; it's just a plane. You set the organization's default to private, and then people are creating records. They can see their own records, but not those of others, and they can change the owner to someone else within Salesforce if they want to. Now we'll move on to role hierarchies and sharing rules, and you can see where this really comes into its own.

6. Role Hierarchies

Role hierarchies exist, and this is where things get really interesting in the context of Salesforce security. We've only looked at organisational defaults that allow access based on people creating records within them being the owners of those records and then only being able to see those records for the time being. And the moment they change that ownership to somebody else, those records disappear because the organisational by-defaults are set to private, and that's all they can see. Now, role hierarchies allow us to open up the security model based on a hierarchy. Now, this could be similar to an organisational chart within your company, so we could have an org chart that looks a little bit like this. So this is a sales team example. So we have the VP of Sales at the top. Now above him we could have the CEO, but essentially he's keeping it simple, just having these three levels. So we put the VP of Sales on top. We then have three sales team managers: teams A, B, and C. And under them, they've got their sales teams—Sales Team A, Sales Team B, and Sales Team C.

Now, users in Salesforce can only be assigned one role at a time. And so I could be assigned to the VP of Sales, or I could be the Sales Team C manager. Now, the crux of role hierarchies is that if I create records, for example, as a sales team C role, then those records that I create are only visible to me within my sales team C, so nobody else can see them at that level. But my sales team's C manager can see them because he's higher up in the role hierarchy. And then my VP of Sales can also see all the records from everybody underneath him in the role hierarchy as well. So, for example, we could have team A as the manager. Now she could be managing a team below her, and she could see all the records of her sales team below her, but nobody else at the same level as her. So she couldn't see the sales team B manager's records, and she couldn't see the sales team C manager's records, but she would be able to see all the records underneath her.

So this is really quite cool because we can start modelling our security around our organisational charts or the makeup of our organization, but it doesn't have to be the organisational chart that we rely on; it could be broken down by product, or you could be breaking it down by territories or sizes of companies. So, for example, sales teams A, B, and C could be broken down based on the size of the leaves that are coming into your organization. As a result, it does not have to exactly match your.org chart. So what does this look like in Salesforce? So when we go into role hierarchies, you'll see that it looks a bit like this. So we can create roles within those under other roles, and then we can edit those and change the names of them. And we can assign users specifically to the different roles. So you can see here what this hierarchy has done. On the left, it will look like Salesforce. You can see there that right at the bottom we've got the "sales team C" role, which I could assign people to. Then, anyone in there creating records can be seen by the person above them in the role hierarchy all the way to the top. So sales team C, their manager, their VP of Sales, and anyone above them are all affected. So, let's take a look in Salesforce to see what this looks like in practice. So here I am, working on the setup. Now I'm just going to dive in and edit a user. And you can see here that this user has the role of CEO.

And as you can see, you can only set one role at a time for a user. Now if we want to go into the role hierarchy, all you have to do is search for "role," and you'll see it's under the managed users section within Salesforce. And here we go. We have different types of roles or setups we could use. This is a territory-based job, so Western, Eastern, or international sales directors are all possibilities. And we got the salespeople at the bottom of the food chain. And you can see here that these sales reps can't access the data of users above them or at the same level as them, but they can view and edit data and generate reports based on that.

The people above them in the role hierarchy, as well as everyone below them in the role hierarchy, can then view, edit data, and create reports for their records. But they can't access the data of users above them or at the same level as them. So that's a territory base. But then, of course, you could have a product base based on hardware, software, and networking products. And also, you can do it based on the size of the company, as I said. So big is the company's midmarket Fortune 10,000 sales group, and so on. But first, let's set up roles. And here is the role hierarchy. Now, this is the default role hierarchy that comes out of Salesforce. So from here, I can assign users to it.

Now if I click "assign" on here, we should see our user that we just saw earlier on "assigned," and there he is, James Johnston, assigned to the CEO role in here. But I always add other people into that CEO role, and they will then have that role and see all the records under them in the role hierarchy. So let's cancel that. So I can also add more roles. So let's add a role here, and we're going to call this a VP of Sales. It reports to the top of the tree, which is a force guru. And I'm just going to click "Save" on this. So now I've created my first role. So if I go back to my roles, here we go, with my VP of Sales at the bottom. So we're kind of starting to create a structure based on the diagram I showed you. So we're going to create our next role, which is Sales Team A. Why should I be the C Manager, reporting to the Vice President of Sales?

So I'll click Save and return to my role. So now I've got my C Manager, and I'm going to put my last role in for that kind of group as my Sales Team C, and then click Save. I can assign users directly to a role from here or create a new user from here. But I'm going to return here and assign it directly from here. So I'm going to add a user directly to my Sales Team C. I'm going to add this user, called Integration user; click Save. And then I'm going to add myself to the VP of Sales. But you can see I've actually made a little mistake on purpose. And that is my VP of Sales, who is actually at the same level as the CEO. So this essentially means that if I sign anybody to the CEO level, because he's at the same level as my VP of Sales, the CEO won't be able to see any of the records from the VP of Sales or anything below the VP of Sales in the sales hierarchy. So I want to now move the VP of Sales to be under the CEO. So it kind of fits nicely with my model. So I'm going to click Edit on there, and all I'm going to do is change the reports to my name and select my CEO, then click Save. And now I've moved my VP of Sales under the CEO.

So now I've correctly set the record accessibility so that the CEO can see everything under him. So what you need to know for the exam is that you can control the accessibility of records within salesforce.org based on a hierarchy. And anybody below the user in the hierarchy can see those users' records, which are driven by the ownership of those records. Now you've also got to remember that anybody on the same level as that user can't see anybody else's records. They're on the same level, and they can't see anyone's records above them in the role hierarchy either. So long as you understand that, you should be fine. If you do have any other questions, be sure to ask them in the comments; otherwise, we'll see you in the next video.

7. Sharing rules

So now we're onto sharing rules. So sharing rules allow us to share records with other people within the system based on record ownership or based on the fields on the record. So, let's look at our.org. chart. So our organisational chart currently looks like this: We have our VP of Sales, sales managers, and our sales teams. Now, what the sharing rules allow us to do is go across that structure. So I can basically share records between, say, Sales Manager A and Sales Manager B across the hierarchy. And this is what sharing rules do. It kind of breaks this very formal hierarchical structure of data and allows us to share records across it. Now it allows us to share records with roles.

So Sales Manager A, along with Sales Manager B, also allows us to share records using public groups. And these are similar to queues, in which we can put a group of users together and allow them to share specific records. So, for example, I could have some sales support users that support two groups of the sales teams. So we could have one public group, which is our Sales Support Team A, which supports Sales Team A and Sales Team B. And I could have another public group that supports Sales Team C only. And then I can put users into that public group, and the moment I do, they have access to the records in the corresponding sales team so they can support them, do all the stuff that they need to do post-sales, and things like that. We can also share records directly with other users.

So, for example, there could be a support user with whom I want to share records within the Sales Team C or something like that. So it's specific groups of records that I can share with other users. So it could be all of Sales Team Manager A's records with another specific user rather than a group of users. And finally, for every sharing rule I set up, I can set up the permissions for it. As a result, access is either private read-only or public read-write. So I can say that I actually want to share all of Sales Team A's records with Sales Team Manager B, but they're going to be read-only. Sales Team Manager B won't be able to edit those records, or it may be with the Sales Support Team that I actually want read-write access to those records; allow them read-write access because they're supporting the sales guys. And finally, we have criteria-based sharing, which is based on the specific data within those records.

So for example, I could say that any opportunity—so any successes we've made in the business, any opportunities—that one I want to share with the entire organisation because I think that is really beneficial because it shows which sales we've won and potentially the upsell and cross-sell opportunities across my sales teams. So let's take a look in Salesforce and see how we kind of set up these scenarios. So here I am in my setup menu. So I'm just going to search for sharing and go to my sharing settings. And here we have the organizational-wide defaults at the top. But if we scroll down a bit further, we get to our sharing rules for the particular objects. Now you'll see here my custom object, the invoice, and the invoice product. If we scroll down to the bottom here, it's not there. And that's because, again, the master-detail relationship inherits all that security from its parent, which in this case is the account. So I can't add any sharing rules to my invoice. So, for my opportunity objects, I'm going to create a sharing rule.

So I'm going to click "new" on here, and I'm going to share my team manager with team manager B. So I'm just going to write a description. So what I'm doing is sharing all of Team Manager A's records with Team Manager B as read-only. Now I select the rule. So this is where I can choose either based on the record owner or based on the criteria and the data on the records. But I'm going to, for now, just leave it with the record owner, and I'm going to select which records I want to share. So, because I share team manager A's record with teammate B, I'll be the sales team A manager. And then I'm going to select the user to share with. So in this case, it will be roles and sharing. Team Leader B. As you can see, I can share roles with either the public group or subordinates. If I chose roles and subordinates and chose Team Manager B, it means all of Sales Team Manager A's records are going to be shared with Sales Team Manager B and all his subordinates, which is not what we want. So I'll just keep it as a role. I'm going to say what permissions I'm going to give.

If we're looking at count access, it's either read home only or read writer private. But, 99% of the time, it will be read and written. And then I'm going to click save on that. Now it does say that the recalculation of the sharing rules will happen in the background. And if you've got a lot of records, this may take a little while. But for me, I've hardly got any records in it at all. So I'll click OK, and it should be finished in a minute or two, and I'll receive an email almost immediately. Now that we scroll down, we can see that my sharing rules have been set up and that it's currently running the background job. You'll notice that I did, in fact, share the opportunity record at that time. It has actually implemented sharing policies in the account and case. And that's because opportunities, accounts, and cases are kind of linked together because of this master-detail relationship, but they're a little bit more flexible, so we can kind of change the sharing rules. So if I refresh this now, hopefully it's been recalculated.

Yes, it has. And it turned out that I didn't need to apply the sharing rules to all of the accounts and cases. It's just valid for the opportunity. So you might get that now and then, but it's usually fine. Okay, so we've created that sharing rule now between Team Manager A and Team Manager B. It doesn't currently work the other way around, so Team Manager A can't see Team Manager B's records. So if we wanted to do another sharing rule, that would do it the other way around. But we wanted that sharing rule to allow all users in Salesforce who have access to opportunities to see any one opportunity, and we can do that using criteria-based sharing. So I'm going to click new here and say allow all users read access to one, misspell it, and always put a description in. Actually, I'm going to just copy what's there.

And this time I'm going to use criteria-based sharing. And now I can say, based on fields within the record, who I'm going to share it with. So I'm going to select here, somewhere, the one right at the bottom. So I'm going to say if one equals true, then who do I want to share it with? Now I could create a public group with everybody in it and share it with them, but what I'm going to use is the role of subordinates, and I'm just going to pick the very top of the chain, which is the CEO. So then it's essentially going to share all the records with everybody in the role hierarchy because I know the CEO is at the highest level. And then also, I want to make sure it says "read only," because I only want read-only access to the records because once they're there, that's it. And I don't want random people editing records.

And I'm going to click save on that. Again, it's going to do that background calculation. As we scroll down, we can see that it has created an opportunity; one plus one equals true. and it's being shared with the role and subordinates of the CEO. Now, this may take a bit longer because I'm actually sharing across the entire role hierarchy. And if you've got a lot of records, this can take a very long time and could affect the performance of your salesforce. org. But if I refresh this, yes, now it's done. And now we can see we've got two sharing rules. The first is our criteria-based sharing, while the second is our ownership-based sharing. So for the exam, you really need to understand that sharing rules go across the hierarchy. allows us to share records based on the values within the records or based on the ownership of those records and be able to share them across the structure using roles, roles and subordinates, groups, or assigning them to specific users within the York.

8. Manual Sharing

So we now have manual sharing in that type of record access part of this module. So manual sharing is exactly what it actually says. It allows you to manually share records within the system on a record-by-record basis. So let's take a look at how this looks inside Salesforce.

So here's my.org. and I'm just going to dive into an opportunity. So here we are. Here's my opportunity here. Now that you have this opportunity, you get a sharing button appearing on the object, which allows you to click and add the manual sharing rules. But it may not be there.

So, first, either add it to the page layout or check the object's organizational-wide settings to ensure the sharing button appears correctly. So first, I'm just going to check the layout. I'm going to go to Buttons. And here's the sharing button here. And sure enough, there it is on my page layout. So it's on there, but it's just not displaying. So now let's take a look at the sharing rules. So I'm going to dive into my setup and search for sharing. There are my sharing settings. I dive down here, and there we go.

That's the reason the sharing button isn't being shown. Isn't it because it's open to the public? This object has essentially no security; there is no record-by-record security. So I need to change that first to private. So I'm going to change my status to "public read only." It will appear for that as well. But I'm going to do Private, then Save and OK. Salesforce is then going to do the recalculation of the sharing rules based on my changing it to private.

I'm just going to refresh to make sure it's finished. Yes, it has. So I'm going to go to opportunities and dive into my record, and there it is. My button has appeared. So, if I click this button, I can see what the current sharing rules are on it. So I can see now that I'm the user, I'm the owner, and I have full access to that record, which makes sense; I'm the owner of the record, and therefore I should be getting full access to that record. So then we can click "Add" to add a manual sharing rule.

So I have the option of adding public group roles and everyone in the role hierarchy under that role, or adding individual user roles. So for the public groups, you can create a group in the Salesforce setup, add a group of users to it, and then add that group here, and it will share the record. So here, Salesforce actually creates one already called "all internal users." So we could have that and say that all internal users have read-only access to this one record within Salesforce. I can also say read and write. So those are the two options.

Alternatively, I could play one or more of the roles we've played before. So I could do both the internal users group and the role, but I'm going to remove all of the subordinates and roles. Or, finally, I could do specific users within Salesforce. So I'm actually going to add James Johnston and get rid of the other roles. I'm going to make sure it's read-only, and I'm going to click save. And now you can see that in my sharing details, I have myself as the owner, which has full access, and I've got James Johnston, who has read-only access. And the reason for this is because of manual sharing.

So the reason is actually quite complex; you'll find quite a few different reasons for why people have been given access. It might be driven by the ownership of an account, which, along with the permissions, has cascaded down to the opportunity. It could be a sharing rule on the object, and they've been granted access based on sharing. But sometimes that can get quite complicated because you'll only get the type of sharing rule that's shared between two roles. And a sharing rule is the reason for the link, but it doesn't say why a specific user has access to that record. If you click "expand list," it actually shows you what access everybody has within salesforce.org, and you can kind of filter based on that if they do have access.

So you can see here that, actually, this security user has read-only access for some reason, but I set this object to private. So why is this security user getting access to this record? Because, by default, if we set the organisational wide defaults to private, only the owners of the record, or the manual sharing rule that I created, should have access, explains James Johnston. So let's take a look at why. So you can basically hover over here, click "why," and it will tell you exactly why. It says that the reason is because they're an administrator. So you can see now that they've got access to the record because that user actually happens to be an administrator. And we can click through to the user and prove that information as well. I can click up here, go into the user detail, and this is actually called an analytics cloud security user, which seems a little strange, but I can dive in here, and if I search for opportunities, you can see here that they have view all access to that object, which is why they can see those records.

So the sharing button is actually quite a useful little thing, and the expand list is quite a useful way of seeing why people have different access to the records. So, manual sharing is pretty straightforward. There's a button that you can put on the records to allow people to share the records. The owners of the records can share them, or administrators can share those records. And you've got the ability to add either public groups, roles, roles and subordinates, or users. And the access you can give is either read-only or read-write. So that's essentially it for manual sharing. So manual sharing is really only for sharing individual records. So if questions come up like that, then that's why we've so far screwed up. If you've got any questions, be sure to ask them in the chat. Otherwise, let's move on.

Salesforce Admin certification practice test questions and answers, training course, study guide are uploaded in ETE files format by real users. Study and pass Salesforce Salesforce Admin certification exam dumps & practice test questions and answers are the best available resource to help students pass at the first attempt.