All | Blog | Nonprofits | Salesforce Donor Management | Salesforce Program Management | Strategic CRM Governance

Ensure Continuity for Salesforce Users with the Summer ’20 Release

Ensure Continuity for Salesforce Users with the Summer ’20 Release

In anticipation of changes coming with the Summer ‘20 Release, we are outlining actions admins can take to ensure continuity for users related to two critical updates. 

Note: Salesforce announced in March this release has been postponed to July 2020 (originally scheduled for June 2020). Find more information here.

Restrict Access to @AuraEnabled Apex Methods for Authenticated Users Based on User Profile

This critical update goes into effect with the Summer ‘20 release. Release note.

What it Means

It sounds complicated, but essentially, it’s Salesforce saying users must be granted permission to use (some) custom code before they can run it. For example: in the Nonprofit Success Pack, the NPSP Settings for Customizable Rollups is powered by @AuraEnabled custom code. So if a user that has not been granted access to this code tries to configure Customizable Rollups, they’ll get an error. In other situations, users might not get an error, but they will experience something incomplete or unexpected.

This update will affect @AuraEnabled custom code whether it is unique to your organization–like something a developer built specifically for your organization–or baked into a third-party app like the NPSP. (Note: Aura is specific to Salesforce Lightning so it’s likely this code was added in the last few years.)

Actions to Take

Step 1 – Determine what code will be affected

For code that is custom to your organization: Contact the developer to identify which Apex Classes will be affected.  

For code included in third-party apps: Take one of the following steps.

  • Contact the app provider to identify which Apex Classes will be affected. 
  • Look for a permission set within the installed package by navigating to Setup > Permission Sets. There should be a permission set from the app provider that grants access to Apex Classes for @AuraEnabled custom code. 

Step 2 – Grant users appropriate access

Now you need to grant access to this code for users that leverage this custom code or use these app(s). 

There are two ways to grant users access:

  1. At the Profile level (more efficient for custom code specific to your organization)
  2. Via Permission Sets (more efficient for code in third-party apps)  

BUT FIRST, TEST

Be sure to test this out in a Sandbox: 

  1. Toggle the update on and off to see the effect on custom features and apps (Go to Setup > Critical Updates and search for this new setting. It can be activated and deactivated until the automatic activation date, July 2020). Take note of the features or apps that don’t work as expected. 
  2. Add the appropriate permissions for impacted users, and test again. Any apps or features that weren’t working properly before adding permissions should resume normal operation.

Guest User Permissions

Updates to Guest User Permissions will go into effect on a rolling basis. The rollout has been delayed from its original schedule, though Salesforce is aiming to require this change with the Summer ‘20 release. We expect Salesforce will be turning it on automatically in April, and orgs will be able to turn it off until the Summer ‘20 release (July), when it becomes required. Release note.

p

Learn More

To learn more about this change and how to respond:

What it Means

Salesforce is changing what Guest Users (i.e. unauthenticated users, or users that are not logged in) are able to do within your Salesforce via front-end engagement tools like Salesforce Sites and Salesforce Communities. Specifically, this security update makes all objects private by default for Site Guest Users. If you are using Salesforce Sites or Salesforce Communities and are not requiring all users to log in, you very likely will need to take action.

For nonprofits, a common case where this update applies is Volunteers for Salesforce (V4S) Sites pages with Site Guest Users (online users): admins must now grant these users additional access in order to view and modify records.

Actions to Take

Step 1 – Allow Site Guest Users to continue to modify records

  1. Enable the Secure Guest User Record Access setting that is part of the Winter ’20 Release: 
    1. From Setup, enter Sharing Settings in the Quick Find box, and select Sharing Settings. 
    2. Select Secure guest user record access.
  2. Once Secure Guest User Record Access is enabled:
    1. From Setup, enter Custom Settings in the Quick Find box
    2. Click Volunteers Settings, then click Manage. 
    3. Click Edit. Select Grant Guest User Update Access. 
    4. Save your changes.

Step 2 – Create Criteria-Based Sharing Rules to grant Guest Users read only access to V4S related records

  1. Create Campaign Sharing Rule
    1. Navigate to Setup
    2. Enter “Sharing Settings” in the Quick Find box, then click Sharing Settings
    3. Scroll down to Campaign Sharing Rules related list
    4. In the Campaign Sharing Rules related list, click New
    5. In the Label field, enter “Volunteers Site Guest User”
    6. In the Rule Name field, leave the default Rule Name field value as is (“Volunteer Site Guest User”)
    7. In the Rule Type field, enter “Guest user access, based on criteria”
    8. Select the records to share:
      • Field: Active
      • Operator: equals
      • Value: True
    9. In the Select the users to share with section, enter “Volunteers Site Guest User”
    10. In the Select the level of access for the users section, set Campaign Access to Read Only
    11. Click Save
  2. Create Account Sharing Rule
    1. Navigate to Setup
    2. Enter “Sharing Settings” in the Quick Find box, then click Sharing Settings
    3. Scroll down to Account Sharing Rules related list.
    4. In the Account Sharing Rules related list, click New
    5. In the Label field, enter “Volunteers Site Guest User”
    6. In the Rule Name field, leave the default Rule Name field value as is
    7. In the Rule Type field, enter “Guest user access, based on criteria”
    8. Select the records to share:
      • Field: Account Record Type
      • Operator: equals
      • Value: [all record types]
    9. In the Select the users to share with section, enter “Volunteers Site Guest User”
    10. In the Select the level of access for the users section, set Default Account and Contact Access to Read Only
    11. Click Save
s

This change is immediate. If there is a lot of data to be shared with guest users, your site might be down for a few minutes while it goes into effect.

BUT FIRST, TEST

Be sure to test this out in a Sandbox:

  • Create your sharing rules in a Sandbox and confirm guest users can see data as you’d expect.
  • Once the new setting is enabled in production, add the sharing rules to a change set and deploy to production. 
s

When you enable secure guest site users, the setting applies to all sites. Coordinate this change with your vendors to make sure all impacts are considered and planned for.

Thanks to Peter Churchill of Bridge Farm Consulting for his contributions to this post.

Fiona Rosenthal

Fiona Rosenthal

Senior Consultant

Fiona joined North Peak in March 2017, following six years as a Salesforce Admin in the private sector. In her previous position, Fiona managed a Salesforce instance of 2,500 users where she configured and customized Salesforce, managed data migrations, and supported the daily needs of her end users.