It’s been a long time coming. We’ve been told about it, any by now many users relying on public communities have done something about it. Salesforce orgs across the world are automatically rolling out a policy to protect data in public communities. Suddenly you find yourself with weeks before the Secure Site Guest User setting is completely enforced – read on to find out what you should do!

What exactly is happening?

If your first reaction to this article is “I ain’t heard of no ‘secure site guest user’ update till you gone and brought it up!”, then you’ve not been reading your emails! Salesforce have announced this policy many months in advance, and we had ample time to prepare. It only affects those of us who host services through a public Salesforce community, so it could also be that this update (and therefore this article) is entirely irrelevant for you.

In the Summer ’20 release, which rolled out around July this year, many orgs found that a setting was automatically enabled. This setting appears in the Sharing Settings page in Setup, and you can opt out of it by simply disabling it from that page. However, the next release (Winter ’21) will permanently enforce this policy, and you will not be able to opt out!

The setting enforces a private data sharing model for the site guest user, which is the user all visitors behave as when visiting a community without being logged in. Effectively, it means these users will not be able to even see records from your org by default, let alone edit them. Creation of records should still behave as it used to. This can affect many different community pages, but I’ve noticed it often with survey-type applications.

This begs the question…

But, why?

One of the biggest issues of the past decade has been data security. Whether it’s data protection laws that have affected the way we browse the web; worries about encryption on various platforms; or the endless torrent of leaks containing people’s personal information; preventing data from being shared with people who are not its intended recipients is a very hot topic. The idea that unauthenticated users would have access to modify data in your org, or to read data that you have not explicitly shared with them, probably turned a few heads over on the legal team’s floor.

The idea is that, by default, all the data in the org is secure and not shared with unauthenticated users.

What do we need to do?

The first thing to do is take stock of how this will affect your setup. One way of doing it is to refresh a sandbox, go into Sharing Settings, and enable the secure site guest user option. You can then test out the various features on your community and see which of them break, if any. Another approach is to read your documentation (which I’m certain every consultant gave you), and use them as a guide. Pretend the user can’t fetch any records from the system. If you use any ISV products, get in touch with their support team now – they probably have solutions ready.

Your goal is to list the data that guest users need access to, and what kind of access. Do they need to see accounts? If so, which ones? Do they need to be able to make changes to them? Keep asking those questions about every relevant object.

Before you actually decide on making any changes, consider whether what you’re trying to achieve is actually safe. Are you sure you want to expose your entire list of clients to anyone who types in the first three letters of their name? It could very well be that the correct solution is to change what you offer to your community.

If you have decided on exposing data to unauthenticated users, there are several tools to consider:

Guest User Sharing Rules

Guest user sharing rules are a new type of sharing rule which you can create in the Sharing Settings page. Pick an object and create a new sharing rule like normal. Only instead of ownership or criteria-based rule, select the guest user option. Then define a criteria for which records should be shared, and to which community’s guest user.

These sharing rules can only ever grant read only access. This means you can expose data, but not allow any changes to it. If you need to allow users to change data, try…

Without Sharing Flows

Flows have been getting a lot of love from Salesforce recently. I personally love the idea of a powerful automation mechanism that doesn’t require coding ability. One of the updates flows received recently is the ability to be run in system context. This now has two modes: system context with, or without sharing. A flow running without sharing has access to records to which the user normally does not have access. This extends to both read and edit permission.

You can create screen flows that perform various actions and place them in your community pages. Just keep in mind that you then become in charge of protecting your data!

Without Sharing Apex

Normally, there are only a few scenarios where the without sharing keyword should be used in Apex. However, if you have custom code modules (Visualforce pages or Lightning components) that can manage their own security, then this option can enable them to access data the site guest user would not normally be able to. As always, you’re effectively granting those modules access to every record, so it’s important to code some strict checks.

Use custom lightning component in a community to replace standard functionality that you absolutely cannot create with the above tools.

Another way to use Apex is by creating invocable methods. These are code modules that expand what you can do with Flows and Process Builder.

What Next?

The above should get you through the vast majority of use-cases for public communities. If you’re still struggling to find a solution that works for you, then we’d love to hear about it and offer a consultation.