Overview

First of all, just wanted to clarify I’m not going to discuss how Salesforce handles security on their end, but rather how you as an admin can configure it in your org.  I would again like to remind you that I highly recommend nailing down the fundamentals of being a Salesforce administrator first regardless of which path you ultimately end up taking.  Salesforce security is so fundamental and universal, it is something that I ask interview applicants for admin positions about 100% of the time.  I should also note that while it’s probably alright to not remember every single different possible way a user could gain access to a record in an interview, demonstrating that you don’t understand the way that security works will always be a red flag for me.

“Security and Access” covers about 15% of the Salesforce Administrator certification exam and “User Setup” covers another 9%.  If you can master your understanding of how and why someone would or wouldn’t have access to a specific record in Salesforce, you’ll be ¼ of the way to being ready for your certification!

Every Job You’ll Ever Have

Every job you’ll ever have, in some capacity or another, will have an element of security to it.  There will be someone or something that you need to protect.  When working in technology, more often than not, the most important asset your company will have, is its data.  This means that you, as the Salesforce admin, will most likely be the keeper of your org’s keys.

For that reason, it is imperative that you learn how to use them in the best way possible!  Salesforce has an easy to remember URL for their series of videos on this topic: sforce.co/WhoSeesWhat!  I’m going to summarize at a high level what the different pieces are but I highly recommend going through the links, Trailhead modules, and gain some experience to capture all the finer points.  I’m continuously learning new things about it all the time!

Profiles

The most basic level of access starts at the profile.  Users can only be assigned one profile so it is very helpful when choosing how to create your profiles, to choose names that capture the type of user they will be.  Profiles contain a TON of different settings.  There are so many, that Adam Torman once rolled out the complete list over 40 feet long down the side of a building:

The basic things you need to know are that these permissions contain the most basic Object, Field, and System level access for your org.  Nothing in Salesforce can restrict access to a user if their profile explicitly grants it.  The Object permissions are often referred to as CRUD permissions.  While this is an odd sounding name (and still amuses me every time I hear it) CRUD is simply an acronym for Create Read Update Delete.  This means you can grant or deny these 4 permissions for all objects.  There are also special permissions on objects such as “View All” and “Modify All” which override all other permissions in the system to give a user in that profile full access to all records of an object regardless of ownership.

Field level permissions on the same page as the Object permissions are set and can be marked as either Visible (allowing editing if the field is editable), Read Only (which includes the visibility permission by default), or left blank (which gives no access).

System permissions include things such as “Lightning Experience User”, “View All Data”, “Modify All Data”, etc can be set here as well and dictate the behavior that a user will have at an organizational level, beyond specific object permissions.  These will generally be specified on Salesforce Help pages if a certain permission is required to complete a specific action.

Access to Apex classes, Visualforce pages, tabs, apps, and other metadata can be set here as well.  Users MUST be assigned a profile and profiles are tied to license types.  It is also important to note that Standard profiles can’t be modified and are updated automatically with new releases.  They can be cloned to quicken the process of creating custom profiles though.

Organization-Wide Defaults (OWD)

Record ownership is key in Salesforce and by default users will have full access to a record that he or she owns.  What about the records of an object that a user DOESN’T own though?  This is where Organization-Wide Defaults (commonly known as OWDs) kick in.  With a couple exceptions, OWDs on an object can be set to one of 3 options:

1. Read/Write – gives all users Edit access by default
2. Read Only – gives all users Read access by default
3. Private – gives all users No access by default

These settings will depend on you asking yourself a few questions such as “What is the minimum level of access someone needs to a record they don’t own?” and “Is there any reason someone would have to access a record that they don’t own?”  As I mentioned, there are some exceptions to this for specific objects but for the most part it will be one of those 3.  These can be set in Salesforce Classic by navigating to Setup -> Administration -> Security Controls -> Sharing Settings or Setup -> Security -> Sharing Settings in Lightning Experience (or simply searching for Sharing Settings in either search bar).

Permission Sets

A common issue when determining access is generally along the lines of “Well, if I give 10 users the same profile, what if 2 of them need slightly different permissions?” or “What if I need to give 2 users additional permissions for a few weeks, but then want them to go back to normal?”  Fortunately, rather than causing you to go through the 40 feet of a building process of creating a brand new profile, Salesforce has thought of this!  While a user can only have 1 profile at a time, they can have many profile extensions, known in the Salesforce world as Permission Sets.  A permission set is just that, a specific set of permissions.  This can range from Object specific permissions, to field specific permissions, to app specific permissions, to system specific permissions.  

Generally it is a best practice to have a specific use case in mind for a perm set and name it accordingly, such as “Convert Leads”, “View All Account Data”, or “Destroy Deathstar App”.  You can quickly swap out and assign permission sets to users to give them elevated privileges either temporarily or permanently.  You can also use these on users of different profiles in case specific individuals from different departments need to access an app, or a tab, or pretty much anything!

Roles Control Records

Probably one of the most important, and simple, statements that I keep in mind from learning Salesforce was something I was taught in a training video once: Roles control records.  This short, sweet, and alliteration friendly, statement refers to the last major component of basic Salesforce visibility, the Role Hierarchy.  Similar to profiles, users are limited to only 1 role.  Unlike profiles however, roles control ability to access records in an org.  Since managers often have reasons to be able to see records of their direct reports, Salesforce has made this easily doable by allowing the admins to assign roles to users that correspond to what the organization’s visibility looks like.  While I would highly recommend (from experience) against overcomplicating the hierarchy, it is possible to have up to 1000 roles.

Sharing Rules

If you have a more complicated security model you’d like to implement, Salesforce allows you to do this as well in the form of sharing rules!  You can implement rules that share records based on specific criteria to various roles, roles with their subordinates, or public groups.  These can be configured on an object-by-object basis.

Team Sharing

The next type of object sharing is of the “Team” variety.  Users can be added to Account or Opportunity teams in different roles on specific records and get additional Read or Edit access without having a relationship to the record owner.  These teams can also be saved in a user’s settings and be re-applied to help the owner work on selling to specific customers on an automated basis.

Manual Sharing

Sometimes there are one off cases where a user needs to share a record with someone else.  Maybe they’re going on vacation or maybe just need a little push from someone on a different team.  This is where manual sharing comes into place!  Users can manually share individual records at their own discretion.  In order to share a record, you must be the owner, above the owner in a role hierarchy, or an administrator.

Apex Sharing

Yet another option for sharing records is by configuring Apex sharing.  I haven’t personally done too much of this but the general idea is that you can create “share” records for any object through code that allow you to extend access of specific objects based on criteria that your developers (or maybe you someday!) define.

Wrap Up

Wow. With all these options for sharing records, there’s no end to the amount of customization you can give to your security model!  Each one depends on your company’s unique requirements.  If you’re ever in doubt about who has access to a particular record, Salesforce has you covered there as well!  By clicking the “Sharing” button on the top of the record (available if the OWD is set to anything other than Public Read/Write), you can see everyone who has access to the record, what their access is, and even click on “Why?” to see the reason behind why that particular user has access.

Hopefully that’s enough to get you started (and pass an interview with me) but just in case it isn’t, feel free to check out the helpful links and the Trailhead modules as a result!  Congrats! You’re on your way to becoming a Salesforce admin!

Relevant Trailhead Modules

• Data Security: https://developer.salesforce.com/trailhead/module/data_security
• User Management: https://developer.salesforce.com/trailhead/module/lex_implementation_user_setup_mgmt

Certification Items to Focus On

Security and Access from the Certified Administrator Study Guide:

• Explain the various organization security options
• Describe the features and capabilities of the Salesforce sharing model
• Given a scenario, apply the appropriate security controls
• Describe the various settings and permissions a profile controls
• Given a scenario, determine the appropriate use of a custom profile

User Setup from the Certified Administrator Study Guide:

• Identify the steps to setup up and/or maintain a user
• Given a scenario, troubleshoot common user access and visibility issues

Additional Resources

Sharing Tips: http://resources.docs.salesforce.com/198/14/en-us/sfdc/pdf/salesforce_sharing_cheatsheet.pdf

More Info on Ownership: https://developer.salesforce.com/blogs/engineering/2013/10/behind-the-scenes-of-record-ownership-in-salesforce.html

Adding and Managing Users: https://help.salesforce.com/HTViewQuickStarts?id=000120152

Salesforce On Security: sforce.co/WhoSeesWhat

Profiles and Permission Set Auditing: http://www.salesforcehacker.com/2013/10/visualizing-users-permissions-across.html

Admin Hero on Security: http://www.adminhero.com/salesforce-security-part-1-record-access/

Manual Sharing: https://help.salesforce.com/apex/HTViewHelpDoc?id=granting_access_to_records.htm&language=en