In last month’s security blog, I provided a high-level description of the Four Pillars of Salesforce security, which controls what a User can see in Salesforce. The next key aspect of security to think about is Profiles, which control what a User can do within the system.

Found under Setup | Manage Users | Profiles, a Profile controls how a User relates to each Object. Configure a Profile too tightly, and a User will not be able to do anything; configure it too loosely, and suddenly a User can edit and delete everything in the system. At OpFocus, we always advise System Administrators to start conservatively with security rather than too liberally. If someone cannot see something they should have access to, they will let you know. However, few people will tell you that they can see too much.

The key thing to remember about Profiles is that they can easily trump all Four Pillars without careful configuration. Everything from Object Permissions to Page Layouts to Field-Level Security is controlled by Profiles, and there is far more functionality than can ever be covered in one blog post. Instead, I thought I would share my favorite tips for maximizing the functionality and configuration of Profiles – tips that I wish someone had told me when I first became a System Administrator (and please pass this blog post along to any new System Administrator you might know!)

1. Pay Attention to Field-Level Security

In my opinion one of the most significant points about Profiles for a System Administrator to understand is Field-level security. Whenever a new field is added to an Object or when a new Profile is added to the Salesforce instance, careful consideration should be given as to whether or not a User has a business need to see a specific field. For example, a number of Users might use the Opportunity Object, but does everyone need to see the Expected Revenue? Taken a step further, if Fields are added that include credit card numbers, Social Security Numbers, or medical notes, it becomes even more apparent why Administrators need to use Profiles to control Field-level security.

It is also important to note that Field-level security is separate from adding or removing a field to a Page Layout. While a User may not be able to see or edit a field in their Page Layout, if they have “Read” access to the Field then they are still able to access this data via Reports. This means a User might not be able to see a credit card number on the actual record, but can easily generate a Report of all credit card numbers unless access is restricted at the Field level.

2. Be Careful with View All and Modify All

It is all too common for Administrators to undo all of their good intentions with Org-Wide Defaults by being too liberal with the “View All” and “Modify All” checkboxes on the Profile. What can the impact of these checkboxes be? If the Org-Wide Default for the Opportunities Object is set to “Private,” but a Profile has the “View All” checkbox selected for Opportunities, then any User with that Profile will be able to see all Opportunities.

Taking it a step further, if a Profile has “Modify All” selected for an Object, then those Users have nearly System Administrator access to that Object. With “Modify All,” a User not only can edit any record, but also by default delete any record. There is no way to give a User “Modify All” access and restrict the delete capability. If a User needs to be able to edit all records within an Object, it is a much better practice to create a “Public Read / Write” sharing rule rather than just selecting the “Modify All” checkbox.

3. Take Advantage of Creating Custom Profiles

While most Salesforce instances come with six core Profiles, System Administrators in Enterprise and Unlimited Editions can create their own custom Profiles to specifically suit the needs of their organization. I personally prefer to always use custom Profiles rather than trying to work with the default ones as it allows me greater flexibility and more control over the User experience.

At OpFocus, when configuring a system, we like to use the company name in any Profiles we create. For example we may clone the standard “Marketing User” Profile and call it the “XYZ Marketing” profile. By doing this it not only helps brand the system but it helps group all of your custom Profiles together in what can be come an extensive list of custom and standard Profiles.

4. Understand “Public Read Only” Org-Wide Default vs. Profile “Read” Access

While an Object may have the Org-Wide Default set to “Public Read Only,” Users will still not be able to see records within this Object if they do not have “Read” access enabled on their Profile. This may sound obvious, but it can easily catch an Admin off-guard. This is particularly important to remember when creating a new Custom Object, as “Read” access will need to be assigned to each Profile that will use this new Object.

5. Enable the Enhanced Profile User Interface

I recommend all System Administrators at least try to enable the “Enhanced Profile User Interface” under Setup | Customize | User Interface. If you decide you do not like it, you can switch it off and go back to the other interface. I like the enhanced interface because all of the related information about an object for a particular Profile can be found in one place.  In one screen it will show the Tab Settings, Record Types, Page Layout Assignments, Object Permissions (Read, Create, Edit, Delete) and Field Permissions, and it saves the Admin from clicking around to check configurations. Please note that enabling this interface will impact all System Administrators in your system, so don’t forget to let your colleagues know before you switch it on!

Conclusion

Because Profiles are so powerful, it is common for System Administrators to only leverage this one aspect of security when locking down their system (something yours truly was guilty of when he first became a System Administrator). However, System Administrators need to take a multi-faceted approach and use all the tools in their arsenal to properly secure the data in their Salesforce instance. The trick is ensuring that setting one portion does not undo other security that has been put in place. If you have questions about configuring the security settings for your system, or feel tepid about the interlocking web of security settings, please feel free to ask for our help!

Lastly, it goes without saying that there is more on security that can be covered in future blog posts, including Manual Sharing and Permission Sets. If there is an aspect of Salesforce security that you would like us to discuss in greater detail, please leave a comment below suggesting future topics to cover, and we’ll do our best to cover them!