An Overview of Sharing and Visibility

Sharing and visibility are the cornerstones of data security in Salesforce. In the context of a business, the first decision that an organization makes is whether to have an open policy, which means all the users can see all the records. Depending on the nature of the business, this is not always possible and some records and/or fields need to be secure and only visible to certain people. If this is the case, the system needs to be set to completely private from the start; then, access is granted using several layers of administration features.

In this chapter, we will cover the following sharing and visibility security features in detail:

• Using organization-wide defaults
• Understanding the role hierarchy
• Applying sharing rules
• Setting team access
• Setting profile access
• Using permission sets
• System and user permissions, implicit sharing, and Apex sharing

With the help of these topics,...

Technical requirements

For this chapter, make sure you log in to your development org and follow along as we work through the different sharing and visibility settings available to a system administrator.

Using organization-wide defaults

The first decision that needs to be made, as mentioned in the introduction, is whether you want to have an open organization, where all data is visible and editable by everyone, or whether any data needs to be restricted from being viewed or edited by certain people. Let’s see how this works with a use case.

Business use case

You are the Salesforce admin for XYZ Widgets. You need to limit the visibility of accounts to account owners and their managers only. The first step is to make sure the organization-wide (org-wide) default settings for the account objects are set to private.

Setting up org-wide defaults

Org-wide defaults allow you to adjust these settings on an object-by-object basis. The following org-wide defaults are available for standard and custom objects:

• Private: This means the records in the object are only visible to and can only be edited by the record owner and anyone above the record owner in the...

Understanding the role hierarchy

Every user record in Salesforce has the option to be added to a role. That role is part of an overall hierarchy. The most common use case is when someone higher in the role hierarchy inherits the permissions to objects of users that are below them. For example, the sales manager role inherits the permissions of someone in the sales rep role as the manager comes above the sales rep in the hierarchy. There are also instances such as Sales Ops where the user may not be higher in the organizational hierarchy, but sits higher on the role hierarchy due to the need to have visibility in all levels of the business.

Business use case

As the Salesforce admin for XYZ Widgets, you need to limit the visibility of accounts to account owners and their managers. The previous step of setting up the org-wide default settings for accounts as private assures you that only the account owners can see the accounts they own. Setting up a role hierarchy will take care...

Using organization-wide defaults

The first decision that needs to be made, as mentioned in the introduction, is whether you want to have an open organization, where all data is visible and editable by everyone, or whether any data needs to be restricted from being viewed or edited by certain people. Let's see how this works with a use case.

A business use case

You are the Salesforce admin for XYZ Widgets. You need to limit the visibility of accounts to account owners and their managers only. The first step is to make sure the organization-wide (org-wide) default settings for the account objects are set to private.

Setting up org-wide defaults

Org-wide defaults allow you to adjust these settings on an object-by-object basis. The following org-wide defaults are available for standard and custom objects:

• Private: This means the records in the object are only visible to and can only be edited by the record owner and anyone above the record owner in the role hierarchy (we will cover...

Setting team access

Teams are a feature available on the account object and the opportunity object. For accounts, they are called account teams, and for opportunities, they are called sales teams. Teams allow you to add users to specific accounts and opportunities. They consist of specific users for whom the record owner can set access to the record.

Business use case

You are the Salesforce admin for XYZ Widgets. The sales manager wants an account team, which consists of an engagement manager and a support specialist, to have access to certain accounts. The account record owner should be able to add two users to the team and grant the engagement manager read-only access, while granting the support specialist read/write access. Let’s see how this works.

Adding a user and setting team access

Team-related lists are available on the account and opportunity objects when the teams feature is enabled. Let’s take a look at what this looks like when adding team...

Setting profile access

Profiles are a very important and powerful security feature. In the same way that each user in Salesforce can have a role, each user must have a profile. Profiles allow you to set access to objects that are more powerful and overwrite other security settings. While profiles cover a multitude of settings, we will only focus on the object settings in the context of sharing and visibility here.

Business use case

You are the Salesforce admin for XYZ Widgets. The sales manager has requested that a group of users, all of which have the Service Manager profile, should have View All access to the accounts object. You will do this by updating the Service Manager profile.

Updating profiles

Let’s take a look at how we access the profile settings. As the following screenshot shows, we can access this setting from the Setup page, as discussed in Chapter 9, Setup and Configuration:

Figure 10.7: Finding the Profiles page from Setup

Let&...

Team access

Teams are a feature available on the account object and the opportunity object. For accounts, it is called account teams and for opportunities, it is called sales teams. Teams allow you to add users to specific accounts and opportunities. They consist of specific users and the record owner can set access to the record for each specific user.

A business use case

You are the Salesforce admin for XYZ Widgets. The sales manager wants an account team, which consists of an engagement manager and a support specialist, to have access to certain accounts. The account record owner should be able to add two users to the team and grant the engagement manager read-only access while granting the support specialist read/write access. Let's see how this works.

Using team access

Team-related lists are available on the account and opportunity objects when the teams feature is enabled. Let's take a look at what this looks like when adding team members to the account team in the...

System and user permissions, implicit sharing, and Apex sharing

In this section, we will touch on system and user permissions, implicit sharing, and Apex sharing.

System and user permissions

System permissions are permissions that apply to all apps, such as View All Data or Modify All Data. User permissions are permissions that are tied to user management and access. Both of these sections can be found on profiles and permission sets under the System Permissions link, as you can see in the following screenshot:

Figure 10.15: Link for System Permissions found on profiles and permission sets

This takes us to the next page, which shows us a list of permissions:

Figure 10.16: List of permissions after clicking the System Permissions link

All of the available system permissions appear under System. Scrolling down on this page takes you to the following section:

Figure 10.17: Users section of System Permissions

As you can see in the preceding...

Summary

In this chapter, we learned that org-wide settings are the foundation of sharing and visibility. If anything needs to be restricted, you need to first remove all access by making the object private, then open up access as needed using various security features.

We learned what roles are and how they are used to grant access to records. We learned how to add ownership-based and criteria-based sharing rules to grant access to records. We saw what the account and sales teams are and how to add them to accounts and opportunities. Finally, we learned how to further grant record access using profiles and permission sets.

In the following chapter, we will cover User Management and Data Security.

Questions

1. What is the first decision that should be made when looking at org-wide settings?
2. What does the Grant Access Using Hierarchies checkbox do?
3. What are the two types of sharing rules?
4. Who can add team members to the account and sales teams?
5. Does the Modify All Data data setting on a profile work if the org-wide setting for an object is private?
6. When would you use permission sets?
7. Where is a permission set added after it is created?

Summary

In this chapter, we learned that the foundation of sharing and visibility is the org-wide setting. If anything needs to be restricted, you need to first remove all access by making the object private, then open up access as needed using various security features.

We learned what roles are and how they are used to grant access to records. We learned how to add ownership-based and criteria-based sharing rules to grant access to records. We saw what the account and sales teams are and how to add them to accounts and opportunities. Finally, we learned how to further grant record access using profiles and permission sets.

In the following chapter, we will cover sandboxes and change sets for project management.