When we build the Salesforce Communities, sometimes based on the customer requirements, we need to provide guest access to the communities. Guest access in basically the unauthorized access to the community. As you can easily understand, any unauthorized access is always a very dangerous things to implement. So we need to make sure our security configuration is strong enough that no internal data is getting exposed to the outside world i.e. unauthorized users. And if situation demands, only the required information(as minimum as possible) will be exposed.

I am going to write down what are the details we should keep in mind while configuring guest access to the communities. To start, let’s revisit some basic stuffs first.

For each communities we build in Salesforce, there will be a guest profile created for us automatically. It doesn’t matter, whether we allow guest access or not, the guest profile will be created for us always.

All guest users i.e. unauthorized users will use this profile to access the community. If we create 5 communities, then there will be 5 guest profiles created. Name of the profile will be Profile. 

Starting Spring’20 Salesforce release, the settings “Secure guest user record access” will be enabled by default. Salesforce recommends using this settings to provide user record access to the guest users through communities. But there are few important things we should keep in mind –

  • OWD will be private for all objects and we can’t modify this one.
  • Guest users are not allowed to be added in any queues or groups.
  • Manually sharing records will guest users are not allowed.
  • Guest users can only be given Read Only access though guest user sharing rule.
So now let’s jump into our fictitious Use Case.
The Great University wants to engage their students by allowing them to provide feedback and ideas so that they can keep on improving their infrastructure, course contents, communications etc. They want students, alumni, parents, teachers to provide their feedbacks without disclosing their names. And to this they don’t need to create any user accounts. University also wants that all feedbacks should be visible to others as long as they are not implemented, rejected or duplicated.
Highlighting few sections to put more focus on these parts of the use case.
Solution:
We will create a custom object called Feedback to store the feedbacks. We will also create the Salesforce community and enable guest access there. Expose the Feedback list view in the community.

Will configure guest profile in such a way that guest users can create new feedbacks and also can see all the open feedbacks. Since we want all the feedbacks to be total anonymous, we will assign all the feedbacks created by guest users to internal default user.

Implementation:
Let’s first create the custom object – Feedback, relevant fields, and list views.

Now let’s create the community called – Let’s Build Better Tomorrow. Below is the authenticated user’s view of the community. List view from the custom object – Feedback is added in the community.

Now let’s enable the guest access for the community. We can do that by –

  • Settings -> All Communities.
  • Click Builder against the newly created community
  • Click Settings -> General
  • Check the box – “Public can access the community”
Once done, if we try to access the community url from Chrome Incognito mode(or from some new browser), we will get this below view (this is guest profile’s view)-
As we can see that Feedback’s list view is not appearing. Because guest profile is not having enough permission to this custom object. Now we need to configure the guest profile and provide Read and Create access to the custom object – Feedback. 
To do that, let’s follow the below steps –
  • Settings -> All Communities.
  • Click Builder against the newly created community
  • Click Settings -> General
  • Click on “Configure access for guest or unauthenticated users”
  • And then provide Read and Create permission on the Feedback object.
Important Note: We can only assign Read & Create to the standard objects, but can assign all CRUD permissions to the custom objects to the guest profile.

Once we provide the access, let’s refresh the same page and here is the view(guest/unauthenticated user’s view) – Awesome

Now one part of the requirement is solved that guest users can create ideas, but can they really see the existing ideas?? No. 
The reason is that these ideas are private and not shared with guest users.
Now we need to write Guest User Sharing Rule like below to provide Read Only access –
Important Note: – We can only provide Read Only access through Guest User Sharing Rule.

With this above change, guest users can see the existing open feedbacks as well(only open feedbacks).

We are almost there. The last configuration – we want to make sure that all created feedbacks should be owned by internal users not the guest users. Let’s do that by –

  • Settings -> Communities -> Communities Settings 
  • Check the box against “Reassign new records created by guest users to the default owner”

Now in the community put the default owner by –

  • Settings -> Communities -> All Communities
  • Click Workspace against the community
  • Go to Administration -> Preferences
  • Select the default owner 

With the above use case, I tried to explain stuffs that should be kept in mind while configuring Guest access. Please provide your feedbacks and if you have any unique use cases in mind, please share in the comments. Thank you.