This article provides an overview of how access to data and functionality is structured in Salesforce, which is primarily comprised of the following:
- Organization Security
- Object Security
- Record Security
- Field Security
- Folder Security
Organization Security
Org-level permissions determines under what conditions a user can login to Salesforce, and is explored in depth in User Setup & Login Process – Free. Â A few key settings are:
- When users can login (Login Hours)
- Where users can login from (Login IP Ranges)
- How users can login (API, UI, etc.)
Object Security
Object-level permissions determines what actions (Create, Read, Edit, Delete) a user can perform on records of each object.
In order to create a record of that object type, the user only needs the “Create” object-level permission.
In order to perform an action on an existing record, the user needs the corresponding object-level permissions and record-level permissions (see below).
Record Security
There are 3 tiers of record-level permissions:
- Read Only
- Read/Write
- Full Access
“Read Only” and “Read/Write” access can be granted through a variety of means (org-wide defaults, sharing rules, etc.). Â Users with the object-level permission “View All” (pictured unchecked above) are granted “Read Only” record-level permissions to all records of that object.
“Full Access” is granted to:
- The record owner.
- Users higher in the role hierarchy than the record owner (when “Grant Access Using Hierarchies” is enabled).
- Users with “Modify All” object-level permission (this includes system administrators).
- Members of a queue to all records owned by the queue.
It is not possible to share “Full Access” via sharing rules or other mechanisms at this time.
Record-level and object-level permissions correspond as follows:
| Create Record | View Record | Edit Record | Delete Record | |
|---|---|---|---|---|
| Object-level permission | Create | Read | Edit | Delete |
| Record-level permission | N/A | Read Only | Read/Write | Full Access |
Required permissions:
“Create” object-level permission on Lead.
Required permissions:
“Read” object-level permissions on Opportunity.
“Read Only” (or higher) record-level permissions on the record.
Required permissions:
“Edit” object-level permissions on Account.
“Read/Write” (or higher) record-level permissions on the record.
Required permissions:
“Delete” object-level permissions on Opportunity.
“Full Access” record-level permissions on the record.
Demystifying Record Deletion within Salesforce
“Full Access” is typically granted to the record owner, users higher in the role hierarchy, and system administrators. Â As shown in example 4 above, “Full Access” record-level permission and “Delete” object-level permission are required in order to delete a record.
This explains why some users may not be able to delete records, even when granted “Read/Write” record access via sharing rules or org-wide defaults.
Important Notes:
- Not all objects will adhere exactly to the above rules (e.g. products, which do not have a record owner).
- If a user can edit (but not delete) a record and has the “Transfer Record” permission, they may be able to transfer the record to become its owner. Â They may be able to then delete the record.
Field-Level Security
Field-level permissions determines which fields a user can view and edit on records of an object. Â Field-level permissions have 2 settings:
- Read Access
- Edit Access
The combination of settings are as follows (it is not possible to have Edit Access without Read Access):
| Result | Read Access | Edit Access |
|---|---|---|
| Field Editable | Checked | Checked |
| Field Read-Only | Checked | Unchecked |
| Field Hidden | Unchecked | Unchecked |
A user must be able to view the record in order to view any fields on the record. Â Likewise, if a user cannot edit a record, they will not be able to edit any fields.
Note: Â Page layouts also influence which fields a user can update within the User Interface, which is discussed in the future.
Folder Security
Folders are used to secure a variety of data within Salesforce, including but not limited to:
- Reports
- Dashboards
- Email Templates
- Documents
You’ll see this similar mechanism used in many areas not specifically labeled as folders as well (such as list views):
Hi John,
Were do you create record level permissions in the org for record owners?
I.E, READ ONLY, READ/ WRITE and FULL ACCESS.
Full access for owners
Hi John,
In Summer ’16 for the Field-Level Security, the labels “Visible” and “Read-Only” have been replaced by “Read Access” and “Edit Access” (respectively): https://releasenotes.docs.salesforce.com/en-us/summer16/release-notes/rn_forcecom_custom_general.htm#rn_forcecom_custom_general
Presumably this means that the new Edit Access label is the inverse of Read-Only: that is, if Read-Only was previously checked, then Edit Access would be unchecked, and vice versa?
Thanks,
Mark
Thanks for the heads up! Haven’t completed the summer 16 updates- that will definitely need to get updated. Makes a lot more sense too!
Yep agreed it makes more sense. One thing though if that second column (edit access) is indeed the inverse of read-only then I bet it will catch some people out when they need to select the opposite of what they used to in that “second column”.
Doesnt OWD use terms like Private, Public Read, Public Read/Write instead of Read, Read/Write and Full access?
I am confused!
Also,
1.If we edit Field level security via Profile/permissions sets we have options Read Access and Edit Access
2.If we edit Field level security via Fields i.e. Object->fields->your Field->Set Field Level Security we have options of View and Read Only
Why this difference in terminology?
OWD sets the object access- read only, read/write, private.
Object level security is defined with read, created, edit, delete access. Profile, permission sets.
Record level security is similar to OWD but also includes full access.
Field level security you can set read and edit access to the field- if you see “read only” that translates to read without edit, and “visible” translates to edit access (without read only checked).
Update materials on this page- going to do some additional reviews
I believe this change only takes effect if you don’t have the “Enhanced Profile User Interface” turned on.
From memory I had enhanced user profiles turned on, but I’m not able to test that now.
What’s the difference between visible and read only? For some reason in my head I’m associating both as the same thing. For a user to have read only access, must they have visibility as well? Sorry to inundate you with questions lately, I’ve been getting very serious with my studying as of lately.
Thanks in advance!
Visible = editable
Visible + Read only = not editable
sorry, I meant to refer to the section “Record Security”, not “Record Access”
Hi John
I am missing a more detailed explanation on how record access is set up by Sharing Rules. It is not immediately obvious from the explanations under “Record Access”. Also, “Full Access” really means “Read/Write” in SFDC terms.
thanks!
Full Access is read/write/delete/transfer while Read/Write is just read/write (no transfer/delete).
Sharing rules extend record access in addition to what is offered by the OWD for that object and the role hierarchy. I would revisit the who sees what series, which may help as well.
Hi John,
Do you have the videos for “security model” topic?
Thanks!
I haven’t personally produced anything because I think the Who Sees What Series does an excellent job.
simply excellent
Hi John,
I am struggling to wrap my head around how record level security comes into play. I have worked some scenarios in my dev org and I can’t seem to get the behavior I was hoping would solve my questions. Here is what I tried:
OWD for accounts set to Read Only
Object Permissions for User A set to Read, Create for accounts
Result: User A can see all account records regardless of owner, can create accounts, and User A can share the records he/she owns.
Next,
OWD for accounts set to Read/Write
Object Permissions for User A set to Read, Create for accounts
Result: Same as above, but User A can’t share the record. I would have expected that with read/write, as the owner of a record, User A would have been able to edit and delete his/her own account records and only read other users’ records.
What am I missing? Doesn’t the record owner have full access to their own records with read/write OWD settings? How would I restrict User A from editing records owned by another user while still being able to edit/delete his/her own records?
Thanks!
Might have just solved my own questions.
In order for User A to edit his/her own records, regardless of the OWD settings, the object level permission has to be set to Edit. If OWD is set to read/write, then User A would be able to edit other users’ records.
What hung me up was that even though the ‘Edit’ button on the account record page was available for records owned by other users (logged in as User A), I got the insufficient privileges message after trying to edit.
Maybe another example above with the scenario of a user having the permission to edit his/her own record but not records owned by another user might be helpful.
Cheers.
Thanks Grant – good thought and a great example of learning by exploration. FYI – the sharing button goes away when OWD is set to read/write, as it is redundant.
Hello,
Which category would Organization Wide sharing setting fall under?
Thanks
Sonu
[Edited] Record level security
Hi john
Are you sure ,it is object level security or record level security?
Explain to solve my mystery
Thanks
Anu
Yeah sorry not sure what I was thinking here- OWD is record level security. Sorry about the mix up
Hi John,
The images are failed to load under the topic – “Security overview”.
Hrm I am not seeing any issues – can you try another browser and clear your cache?
Re: Field level security. If I go to Profile settings and then Object Settings and select an object (for example, Accounts), the checkbox columns for Field Permissions say “Read” and “Edit,” not “Visible” and “Read Only.” I know I’ve seen Visible and Read only somewhere in the Settings area, but I can’t find where!? What am I doing wrong?
Click on the field itself in setup, and then click View Field Accessibility – the info is the same, just presented in different places/formats.
Got it! Thank you 🙂
Got it. So most restrictive access level would be valid. Tx again
@John, what happens if you do the following –
1. Read access at object level and Read/Write at Field level
2. Edit access at object level and Read at Field level
and other such configurations?
Thanks.
Least access:
1. read at object and field
2. read at field, but can potentially edit other fields on the object
Also consider that you would have to weigh in with record-level access as well 🙂
How do you GET to the folder security outlined above? Is it only available when a role hierarchy has been set, or only for certain editions? I can’t find it anywhere in my professional edition, nor in the [enterprise] NPSP I’m starting to work on, which doesn’t have a role hierarchy and may not need one.
Its more of a concept – this refers to the security that is configured on the list view, dashboard folder, etc. When you modify a list view for example, who can access that list view is a setting at the bottom of the list view config.
When do you use Organization wide defaults?
To set the record level security for all records within an object for all users in the org.
You write
As shown in example 4 above, “Full Access” record-level permission and “Delete” object-level permission are required in order to delete a record.
This explains why some users may not be able to delete records, even when granted “Read/Write” record access via sharing rules or org-wide defaults.
In the second sentence, shouldn’t “Read/Write” be “Full Access”. I thought that the point that you were trying to make was that even if a user has full access to a record they might note be able to delete it because they don’t have the ‘delete’ object-level permission.
No – you need the delete object level permission AND full record level access. Read/write and full access are not the same – that’s the critical part of the story above.
You write
As shown in example 4 above, “Full Access” record-level permission and “Delete” object-level permission are required in order to delete a record.
This explains why some users may not be able to delete records, even when granted “Read/Write” record access via sharing rules or org-wide defaults.
In the second sentence, shouldn’t “Read/Write” be “Full Access”. I thought that the point that you were trying to make was that even if a user has full access to a record they might note be able to delete it because they don’t have the ‘delete’ object-level permission.
No, the point I’m trying to make is that if the record is shared with read/write access via sharing rules, they may not be able to delete the record even if they do have delete access, because they wouldn’t have full access to the record.
Full Access means permission to Create, View, Edit, Delete and Transfer records.
Read/Write is not the same as Full Access because it does not include DELETE or TRANSFER.
https://help.salesforce.com/apex/HTViewHelpDoc?id=basics_record_access_levels.htm&language=en
I found this SFU video to be very helpful and a good compliment to your content here: https://www.youtube.com/watch?v=17dr2GMvgd8. About 30-40 min is dead air while workshop attendees confer at their tables so it’s not as long as it initially appears. Thanks, John for great site.
Thanks Chuck – added to the security section
What level of security can you set for Professional vs. Enterprise?
For the majority of settings, Professional and Enterprise should behave identically.
Professional does not support record types, which does have some impact on security (page layout selection).
I thought the Field Level Security video indicated that Field Level Security was only available for Enterprise, Unlimited, Performance, and Developer Editions (and therefore NOT Professional). Did I misunderstand?
Just double checked, that is correct PE does not have FLS.
In addition, I believe that custom profiles are not available for Contact, Group, and Professional Editions.
I’d have to check the docs for the specifics, but yes custom profiles are not supported in professional edition.
To recap:
Professional edition and below [edited for clarity]
-no field level security
-no custom profiles
-no record types
Enterprise and above
-FLS
-custom profiles
-record types
Thanks for the discussion here folks – I don’t use professional edition often, so this has been a refresher for me as well.
Did you mean to say “Professional edition and below”?
Yes, thanks for pointing this out. Updated, sorry about that!
Just reviewed this section again, and would like to suggest you change “example” to “column”. To me, it’s the fourth column.
John-
The Department of Redundancy Department called…
“Full Access” is granted to:
The record record owner.
🙂
Still says “The record record owner.”
Got it, updated. Thanks
Excellent summary!
Very aptly summarized.
3rd bullet has a typo under ‘Organization Security’
Thanks, fixed.
FYI: the word “IN” is missing in the sentence: “Note: Page layouts also influence which fields a user can update within the User Interface, which is discussed the future.”
Thank you, updated!