Learning Salesforce security is similar to learning to fly an airplane. I'm going to give you some pointers on how to better pilot the Salesforce Security plane, the essential “gauges” you need to know, and how to navigate and land it safely.
I'm a member of the Trailhead team, a Salesforce Certified Administrator, and a Lightning Experience instructor that teaches Administrative Essentials for New Admins. As a senior application instructor, I spend my days attempting to break down complex subjects into digestible chunks (while also making my sessions enjoyable!).
Piloting Security
One of the most appealing features of Salesforce is its security model's flexibility… It's also one of the reasons it can take some time to become used to. When it comes to security, I, too, found some of the measures to be… a little hard.
Safety First
Clients trust you to keep their information safe when you store it in Salesforce. One approach to achieve this is to ensure that you only share information with those who actually require it. Invoke the concept of least privilege, which states that people should only have access to the information they require to do their jobs.
The following are the five areas you must master:
-
Defaults at the Organizational Level
This may appear to be a difficult task, but it isn't. Organization-Wide Defaults, or OWDs, are a useful tool for displaying your data model. Are you a private person, a public person, or a hybrid? All data is shared with everyone in a public setting, however, in a private setting, we lock down all information at first and then selectively open it available to those who need it.
A hybrid is a model that falls midway between the two. The rest of your Security settings are affected by how you configure your OWDs.
- Profiles
You'll hear a lot about profiles once you start studying security. Many things, like Object access, are determined by the profile that is allocated to you. Do you have groups of workers with comparable job functions that need to access data in the same way? Salespeople, for example, may require access to opportunities, whereas service agents may require access to instances. Access requirements for different categories of users can be classified using profiles.
-
Permission Sets
These are extra permissions that you can add to your profile. You might have as few as one permission set or as many as ten. You might have a sales representative with a sales profile who, unlike other salespeople, requires access to a certain object. Permission sets work in the same way that the word “and” does. You'd offer the salesperson access to the Sales profile as well as anything else.
-
Role Hierarchy
The hierarchy of roles extends to record access. Do you want to view the opportunities your salespeople are working on as sales managers? Yes, of course! Just because you have access to one object, such as Contacts, doesn't mean you have access to all of them. Your firm may have 1,000 contacts, but you may only have access to 200 of them by default.
Access to records on objects can also be rolled up using the role hierarchy. A sales manager, for example, who is placed above the sales reps' hierarchy, will have access to all of their records as well as her own.
- Sharing Rules
You can share information horizontally using sharing rules. Rolling up access is the whole point of the role hierarchy, but what if you want something different? Perhaps you have two sales representatives, one who focuses on New York businesses and the other on San Francisco businesses. Is it conceivable for a company to have a presence in both cities? Yes, absolutely!
And, if that's the case, wouldn't it be amazing if each salesperson knew what other deals are in the works that would affect their own? Yes! As a result, you may desire to share all sales representative records with one another in this scenario. Sharing rules can assist you with this because they are on the same level of the role hierarchy.
