Three Steps to Reviewing your Data Security in Experience Cloud

With new reports every day about data leaks and security breaches, making sure your organization’s data is secure is top-of-mind for many institutions. The Salesforce platform is built on trust and transparency, but your team shares the responsibility for keeping your data secure by ensuring that you and your organization have configured your Salesforce security settings correctly.

A common mistake we see is Admins trying to secure their data by removing fields from page layouts or creating custom UIs. While methods like these may make your data more difficult for unauthorized users to access it, they won’t restrict access completely. If records and fields are not secured at the Salesforce application level, they are not as safe as they should be.

The Salesforce Security Implementation Guide goes into great detail about all of the steps you can take to secure your org, and we strongly recommend that Salesforce architects and developers get to know it intimately. For this blog post, however, we’re going to focus on the three most powerful means to secure your data when you are using Salesforce Community Cloud.

Step 1: Determine What Access Your Users Should Have

If you remember only one thing from this post, it should be this: users should only have access to the minimum amount of data that they need to interact with your organization. You should begin any implementation by creating a security matrix that lists out all of the internal and external personas your organization needs to interact with, what data they need to access and what they need to do with it. Try to get as granular as possible when putting this together. If you have already implemented Salesforce, it’s not too late to do a thorough review of your users and their permissions.

Step 2: Secure Your Objects and Fields

Once you’ve finalized your security matrix, the next step is to create profiles for each persona and use Object Level Security and Field Level Security to restrict access to anything that doesn’t have a “Yes” in your matrix. You can use Validation Statuses to verify that you’ve set things up correctly when you finish.

Object and Field Level Security should be a familiar concept since they’re also used to control access throughout Salesforce, but when it comes to Communities, these concepts are even more important if you use Anonymous or Guest Profiles.

These types of profiles give unauthenticated users access to a community and are typically used for the first time someone interacts with your organization. There are a number of good reasons to use them, but be careful to provide the absolute minimum amount of access needed for that initial contact. If someone wants to interact with your organization further, encourage them to create a profile so their access can be tracked.

Authenticated Profiles, on the other hand, are for community users who have a username and password, and can access additional content in your community after logging in. There may be other processes that these users have access to as well, such as approval processes. These users can be granted additional access, but you should still keep the objects and fields that they have access to as restrictive as possible. Every community user should only have access to whatever data is absolutely required to engage with your organization.

Step 3: Secure your Records

While Object and Field Level Security can be used to restrict access to the objects themselves, you’ll most likely also want to restrict access to certain records. As an example, you may want to allow your Community users to update their own contact information without allowing them to view or update any of your organization’s other contact records.

• Use Organization-Wide Sharing Defaults (OWDs) to define baseline access to records (i.e. Public Read/Write, Read Only, Private, etc). You can also enable External Sharing to create a separate sharing specifically for communities users in scenarios where you want to provide additional access to certain objects for internal users. In either case, OWDs should never be used to grant Public Access to records associated with an object that contains sensitive data, such as Social Security numbers or other personally identifiable information.

• After you’ve set up your OWDs, you can use Sharing Rules to make exceptions to them by giving users in specific groups, roles, and territories additional access to certain records. An example of where this functionality might be useful is in a partner community when you restrict access to accounts, but still allow each individual partner to access the account records that they’re responsible for maintaining. This can get tricky, though, because it’s possible to create sharing rules that conflict with each other and inadvertently provide your users with access to additional records. So double check any Sharing Rules you create against your security matrix to make sure that you’re only opening records up to the intended groups.
• A lot of Child objects are set up to inherit sharing settings from their Parent objects. In cases where they aren’t, you can use Sharing Sets to grant access to them if needed. An example would be granting access to records where the contact ID of the logged in community user matches the contact ID referenced on a custom object. These should also be checked for inconsistencies to make sure they aren’t unintentionally providing additional access.

For further reading, see:

This blog is part of our larger “Ask an Architect” content series. To learn more about engaging a Salesforce.org Customer Success Architect in your organization, please contact your Account Executive.

About the Authors

Tom Leddy is a Director of Education Services at Salesforce.org. As a certified Salesforce Architect, he advises education industry customers that are undergoing digital transformation efforts to help reshape their organizations and serve their constituents more effectively. He also leads multiple Salesforce.org community efforts, including the Ask An Architect content series and Architect Academy Roundtables series. Tom is a published author, public speaker and marathon runner based in the Chicago area. You can connect with him on LinkedIn, Instagram and Twitter

Carlos Villalpando is a Director of Education Services at Salesforce.org based in the Twin Cities area. He has been working on IT strategy for the last several years architecting, developing and re-engineering processes to make them efficient and aligned with the business that they serve.

Originally published at https://www.salesforce.org.