Lately, we’ve seen a significant uptick in our clients implementing Salesforce Communities. Communities are ideal for organizations that deal with “clients” such as in housing and social services space. While you can create an online form for your clients to submit information, if you’d like for them to track their progress or exchange information, that’s where you may want to consider Customer or Partner Communities.

Like most features in Salesforce, Communities are pretty straightforward to set up, no need for complex code. That also means that it is easy to overlook key areas such as data security while configuring your Communities. Improper security settings can expose your internal data to clients, as well as have client’s see each other’s data – not good! What I am writing is not a comprehensive guide to setting up security for Communities but just some areas that we’ve seen get missed and often. I highly recommend reading the Salesforce Security Implementation Guide (131 pages :)), however these tips can help with some commonly missed areas of security.

With the “External Organization-Wide Defaults”  feature it is now possible to separate out the external and internal sharing settings. Earlier you had to start by making all objects that you planned on sharing with the community “Private”, then create layer upon layer of sharing rules on the object to open up access to your internal users. The new External Org-wide Default setting eliminates the need to do that. I highly recommend turning these on in your org (don’t be lazy, do it in the Sandbox first!). See this link on how to enable this setting.

As an example, you may have a Public Read/Write OWD for internal users for an object called Classes, while keeping the records Private for all external users so the student can only see the Classes that he has enrolled in. Make sure that you set the External OWD to Private if you only want the user creating the record and their subordinates within the same Account to see the data.

Remember that OWD settings work together with Profiles and Roles, and you cannot use them to grant users more access to a record than allowed by the Profile. In other words if your Student Community Profile has a Read Onlypermission to the Attendance object, even if you set the External OWD to Public Read / Write, Students can’t create or update their Attendance record.

Another common area that I’ve seen overlooked is the List Views, especially since it is easy for users to create them and not select the appropriate setting. Although it takes some of the flexibility away, consider turning off the “Manage Public List Views” permission on Profile. Users can still create a new View and Clone an existing one, however it takes away the option to share a view they create with external users (the middle option).

Security in Salesforce is flexible enough to be designed for your organization’s particular requirements. It is also an area that needs careful planning, even more so when you are dealing with external users accessing the information.

Sandeep Banga is the CEO of Acutedge. He started his career as an Architect, loves motorcycles, Pink Floyd and using technology to solve problems for his clients.