One of my favorite features of Salesforce is the ability to share information with your community, be it through the Partner Portal or Customer Portal, Salesforce Sites, Siteforce, or Salesforce-to-Salesforce. Bringing a Salesforce Cloud to your community is a great way to foster better and more efficient communication.
But cloud computing is a lot like a first date. Sometimes too much sharing can be a bad thing. It’s important not to expose too much data or give the wrong data to the wrong people. Here are three easy steps to make sure this doesn’t happen:
1. Organization-Wide Defaults
Adopt a private sharing model for objects you plan to expose in the customer or partner portal. This ensures that partners and customers only see records they own, records below them in the role hierarchy, or records that are shared with them. You can maintain a public model for objects that you don’t plan to expose in a portal as long as you don’t grant the portal user profiles CRUD permissions (Create-Read-Update-Delete) to these records.
2. Sharing Rules
Use sharing rules to create exceptions to the organization-wide defaults. For example, if you have set leads to ‘private’ but want to have an internal public model, create a sharing rule such as the following so that all internal users have visibility to all leads regardless of whether these leads are owned by internal or external users.
Review all existing sharing rules, and pay particular attention to any that have a “Shared With Roles and Subordinates” setting since you may be inadvertently exposing records to portal users. This is a very common occurrence for companies that have recently implemented a portal but have not updated their sharing rules. Thankfully you don’t have to delete the rule and re-create it. You can use the Convert Portal User Access tool in the portal setup to migrate these rules.
3. Profiles
Check externally-focused profiles to ensure that these profiles do not have any extraneous object access. Many companies don’t uncheck object access (especially when new objects are created), which means these records may display in the results when portal users do a search.
Also, remember to check public permissions (e.g., Manage Public Documents, Manage Public List Views, Manage Public Reports, and Manage Public Templates) on internal profiles to make sure that a limited number of users have access to these permissions. Otherwise, when an internal user creates a list view (for example, one called “My Hot Leads!”), the default setting is to show this list view to all users including portal users. While the list view may not return any data to the portal user, the portal user will still see the list view name.
Finally, review the “Run Reports” and “Export Reports” permissions on portal profiles to ensure you give these permissions to the correct users (if appropriate).
Remember…
- Salesforce offers many ways to control what data is shared, but you can accidentally leave yourself exposed!
- Business processes change, so security reviews should be an ongoing process and not just a “one-off” as part of the initial implementation.
- It’s easy to hide or inadvertently share data as well as folders and list views. So conduct periodic security reviews to ensure the right data is being shared.
Hi Kara!
Is there an intention to enhance Dynamic Groups? Would be awesome if User record attributes, criteria, could be used to assign users in/out of a public group.
Taking it beyond the Portal space, and use it to manage our internal public group space.
Thanks,
Diana