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
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.
Highlighting few sections to put more focus on these parts of the use case.
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.
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”
- 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.
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.
I tried it in my org. Beyond awesome! Thank you! I would make only one small change on the Status Criteria. Instead of saying 'Not Equal to' Completed, Rejected, I would choose 'Equal to' Open. This is because when I left the field blank, the record showed up in the Community. Thanks again!