9. Object Permissions and Record Access
So I just wanted to mention how object permissions relate to record access because up to now we’ve been talking about how the sharing rules work and how the permissions work within the objects and how you share those records, but there’s a little bit missing in that piece on how it relates to object permissions. So far, we’ve discussed security settings, including core security settings, organization-wide defaults, key sharing rules, and manual sharing. But there’s a little piece at the bottom, which you probably noticed with the triangle cut off, which is object permissions.
And this is all driven by the profiles and permission sets, and it’s essentially saying that a user needs to have access to the object to allow them to see it and for the organizational-wide default sharing rules and everything else to work. So they need to have access to that object, and they need to have permissions, which are all kind of encapsulated within the profiles and permission sets, before you could even get to the organisational defaults for that object or that particular user. So it’s just something to remember when you’re setting all this up. Well, if the user doesn’t have access to the object within the profile, he can’t see the object. So really, the whole security model is pointless because we can’t see it anyway. So yeah, make sure you kind of keep that in mind, but we’re going to now go into a lot more detail about the profiles and permission sets and the nuances within them. So I look forward to seeing you in the next video.
10. User Profiles & Permissions
profiles and permissions. And this is where we talk about how we assign permissions to users. And we can do this in two different ways: either via a profile or via a permission set. Now, the two main differences between a profile and a permission set are that I can only assign the user to one profile at a time, but I can assign multiple permission sets to that user. So I think of a profile as kind of like the base permissions that I want to give a user. So, for example, if I have a sales team, I use a profile to kind of give the general permissions that I want to give to all those sales people. So it could be the objects I want to give them access to, or maybe some of the system permissions that I want to give them access to, like reporting or something like that. And then I use the permission sets to kind of give additional functionality to individual people who are potentially within my sales team.
So that could be creating reports, because I only want to give that to certain people within sales who actually know how to create reports. So let’s take a look at how this works. So now that I’m in my setup, I’m going to go into users here and take a look at my user. Now, from here, you can see that I have a profile, which is called “system administrator,” and you can click to go through to see that profile. But as you can see, there’s only one profile there that’s assigned to me, which is my base permissions. Then, if I scroll down, you can see I’ve got a list of permission sets. Now, there aren’t any in here, but we’re going to create one in a minute so I can show you how it all works. But let’s first go and take a look at our profiles. So here is the list of all the profiles that come bundled with Salesforce when you create a developer.org. You may not have all of these features and functionalities in your production because many of them are optional features that you can purchase to enable in your salesforce.org.
So, for example, the analytics cloud, which is an analytic service that you can buy from Salesforce, But if I scroll all the way down, the two main profiles are the standard user and the system administrator user. So if I dive into the standard user, here you can see the permissions are broken down into two sections. We’ve got the apps, and we’ve got the system permissions. So if I dive into the first one, which is assigned apps, you can see here that it lists all the apps that are on Salesforce, and I can assign specific permissions to all the users that have the standard user profile.
So at the moment, you can see that actual standard users, if they’re assigned to this profile, can see all the apps except for this sample console. And you can see that the default one is RadnipStudios, which is essentially saying that when they log in, this drop-down list is going to show all the assigned apps that are listed here in their list. But the default one is going to be RadnipStudios, which it is because, as you can see, when I logged in, it went straight to Randi Studios. So if we go back out of there next, let’s take a look at the object settings. Now this is where I spend most of my life, basically looking at object permissions and changing field permissions and things like that. So let’s dive into accounts. And here you can see that the first thing is tab settings. So here, I can say if the account number appears on the bar up here.
So if I click edit on this, as you can see here, I’ve got three options. I’ve got a tab. Tab hidden. Off and on by default. So “default on” is basically saying it will appear in my tab bar along the top. Default off basically says yes, it’s going to appear in my menu at the end, and it can be added to the bar, but it’s not going to be shown on the bar by default. I have to navigate to it using the plus sign, and then Tab hidden means that this tab is not visible and that the user cannot access it in any way. So those are the three settings for that. So I’m just going to cancel that. We received the record type settings that I discussed in the record types section of this course. Then we have object permissions.
So you must remember that the object permissions here in the profile or in the permission sets will override what the sharing rules say or the organisational defaults. So for example, if I say they have no access to this object at all within the profile, then there’s no way for the sharing rules to allow me to have access to any records. I must have at least a minimum of read access to allow the sharing rules to do their job. But you can also see we’ve got “view all” and “modify all.” Now these are really powerful permissions within Salesforce.
The View All option essentially states that I want this user, who has this profile if this option is selected, to be able to view all records within the account object regardless of any sharing rules. And the modify all is the same, but it’s actually for modifying it. So editing and deleting records So these are really powerful things. So if you want to bypass all the security on the object, then give the user access to one or both of these options, and then we have field-level permissions. So, based on all of the fields on the object, do I want to grant them read access and do I want to grant them edit access for those fields? If I untick it like this, “clean status,” it’s going to be just read by them. So they can view it, but they can’t edit it.
So if we dive in from our object settings, you can see that you can get into all the other objects within this as well. But I’m going to go back up to my profile and go on to the next one, which is app permissions. Now, these are specific permissions for the apps within Salesforce. So Salesforce has a call center app within it, and here you can set the permissions specifically around that app. They have Salesforce content, which allows people to upload files into content libraries, and here you can allow people to change and manage content permissions within those content libraries. Then we have the Knowledge App, which is again for the Knowledge App within Service Cloud, and other permissions like that. So they’re all specific Salesforce apps. So let’s go back to the overview. Now we have a load of developer permissions—assigning Visual Force pages and things like that—and then we get onto the system permissions.
So let’s dive into the system permissions. Now, I think of these as the specific permissions around the features within Salesforce, but don’t confuse these with feature permissions that appear on the user record. Salesforce refers to feature permissions as a checkbox on the user record. And then within the profile, when you’re kind of giving access to allowing people to create reports and things like that, these are called system permissions. So somewhere in here, if we scroll down a bit, you’ll see some permissions for reports. So, if I search for that, we’ll see that we need to create and customize reports. And here you can see that if I enable this for the profile, the user will be able to create, edit, and delete reports in personal folders. If I tick this box, it will also tell me what other permissions will be enabled.
And you can see here that the permission to run reports will also be enabled if I tick this box. Which makes sense because it seems pointless to create and customize reports if you can’t run them, and we can scroll down and find a slew of little features for doing this, that, and the other when it comes to exporting reports. If you want people to be able to export data from your salesforce.org, that’s kind of an important one to know about. If we scroll down a bit further, there is a very powerful feature in here, one of which is called “View all data.” This will override all of your object permissions and sharing rules, and it basically says that if this profile has this enabled, then all users assigned to this profile will be able to view all data in it regardless of the object permissions and sharing rules within them. So this is a really powerful one.
More powerful than “View All” is “Modify All Data.” And the modified data again does exactly what it says. It enables users to modify all records across salesforce.org, regardless of other security settings. So this is a really powerful feature, and if you hover over the eye, you’ll notice that because it’s such a powerful setting within Salesforce, it actually requires a lot of other permissions to be enabled. Another one could be that the password never expires.
Again, I only use this for integrations; otherwise, I leave it off, and that’s pretty much it. You have some more specific admin permissions for users at the bottom to allow specific users to manage, create, edit, and deactivate users within Salesforce, or we don’t want to give them access to everything else, but that is essentially what system permissions are. So let’s dive back into the profile. Now, within the system we have, We now have login hours in the system section, which is a really cool little feature. It allows you to define the hours during which the users assigned to this profile can log in. If you’ve assigned login hours to the profile and it’s approaching the hour when they’re not supposed to be using Salesforce, Salesforce will essentially kick them out.
Well, they’ll be able to see the last page they’re on, but the moment it ticks over to the following hour and you’re saying yes, they shouldn’t be logged in, the moment they try and navigate anywhere else, it’ll kick them out of salesforce. Also, I use the login hours if I want to kick everybody out of Salesforce, maybe to do a major upgrade to Salesforce. So if I wanted to do that, I just matched the start time with the end time, which basically says that the user will never be able to log in on Mondays. And if I wanted to clear that by clicking the Clear Times button, now they can log in at any point on a Monday. All these times are based on your settings. As a result, My is set to London time. So, if I had users in the United States and wanted to set the time zone for when they could login, I’d have to do it in London time.
So if I exit that, I’m going to click cancel, and then I’m going to go back to my profile and look at the next one, which is login IP ranges. Login IP ranges now essentially instruct Salesforce to only allow users to log in using this specific IP range. Don’t get this mixed up with network access. So if I search for network access here under the security controls, this works slightly differently. What you’re saying here in the profile is that you’ll only allow the user to log in between this start IP address and this end IP address. And if they log in anywhere else outside of those IP ranges, just don’t allow them in. But with network access, when I set the IP ranges on there, it’s essentially saying this is an untrusted source, and those users logging into Salesforce don’t need to activate their connection by getting an email with a code in it or using a two-factor authentication mobile app or anything like that.
So it’s really important to understand those two differences. So I’m going to go back to the profile overview again, scroll down, and finally, I’m going to take a look at session settings and password policies. Now here in the session settings, there are really just two options, and this is basically setting the timeout for users that are using this profile. So here you can see it’s been 2 hours of inactivity, and this is based on the security settings within salesforce.org, but these will override your default security settings in salesforce.org, so be aware of that. And then lastly, we have password policies.
Again, this is very similar to the security password settings in password policies under security controls, except that this is specific to profiles, and these will override what’s in the security controls. Finally, back to profiles, and that’s pretty much it for app and system permissions. But before we go, I’m just going to dive into accounts so you can quickly get to objects and permissions so you can modify everything I told you, all the data. I can click here and it jumps straight to it so I don’t have to go trawling for the settings. But I can also go to accounts and jump through to the accounts object. Assume I want to change the permission. So I want to make all the standard users that are assigned to this profile view all records within the account. So I click edit, and then I go to click view all. But you can see that they’re all read-only. I can’t change any of these. And this is one of the problems with standard profiles. So if I go back to my profile list, essentially all these profiles here that don’t have this delete button next to them and have this tick in this box are all standard profiles, and you’re limited in what you can edit within them.
So as a rule of thumb, I never assign users to standard profiles. I’ll always clone an existing profile and assign them to that. And that allows me to know that if I ever need to change some of the permissions that are kind of read-only in the standard profile, I won’t have any issues. So I’m going to do that right now. I’ve got my standard user profile here; I’m just going to click the clone button, and I’m actually going to call this Radnip Standard User, and click Save. So I’ve now cloned all the permissions from the standard user and created a new profile called Radnip standard user. If I go back to the Accounts object within this window and click Edit, I can now choose View AllData or disable all access to the object entirely. So if I disable access to this object completely, there’s no way for this user to get access to this object unless it’s been set in a permission set, which is a nice segue into permission sets. So let’s dive into permission sets.
So remember, permission sets are essentially additional access that you can grant users, and you can create multiple permission sets for them. So I’m going to click New and type CreateReports, and now I’m going to set a license. So you need to assign a specific licence or set it to none. It’s not a problem. And this is because certain licences may have additional permissions that aren’t available in other licenses. However, I am aware that the Reports permissions are all generic across many licenses. So I’ll just leave it like that and hit Save. Now I’m going to search for that report’s permission. There it is. Create and customise reports. There it is. I’m going to click Edit, select Create and Customize Reports, and then click Save. So there we have it. Now I have a permission set that I can assign to anyone in my salesforce.org account to give them the ability to create reports. And if I want to extend that permission later on, all I need to do is edit this permission set, maybe change the name a little bit, and give them additional permissions; that will be reflected across all the users. So it’s kind of a nice little way of giving additional permissions without having to have hundreds of different profiles.
So now all I need to do is assign my users to it. So I’m going to dive into my Users tab, I’m going to dive into James Johnston, I’m going to scroll down, and I’m just going to edit my permission assignments and give him the Create Reports permission. So I clicked Save, and there we have it. So when James logs in, Salesforce is going to look at his profile, give him all the permissions, and then it’s going to look at all the different permission sets he’s got assigned to and grant him all those permissions as well. Now, one thing I just wanted to show you is that if we go into the permission sets and view that permission set again, you’ll see it looks very much like a profile. There’s really not much difference except that if you scroll down, you’ll notice it only has one option, which is the system permissions. We don’t get the password policies, the session settings, the login hours, and things like that. They’re not in there. So if you do want to make any changes with those, unfortunately, you can only change that in the profiles, and that’s about it for profiles and permission sets.
But just remember that you can only assign one profile to a user, but you can assign multiple permission sets to a user. And also, there’s a little bit of difference between a profile and a permission set where you get fewer of those system permissions, login hours, and things like that. Furthermore, permissions are always increasing. So every time you create a new permission set, you can only give additional permissions; you can’t take away permissions, and if you set those object permissions in the profile of permission sets, they’re going to potentially override what you say in sharing rules. So if you don’t give access to an object to a user within a profile, then they’re never going to be able to see any records in that object, regardless of the sharing rules that you give them. So if you do have any questions about this video, please be sure to ask a question in the comments. Otherwise, I’ll see you in the next video.
