In the Summer ’19 release, Salesforce are making significant changes in how access to data can be managed for customer and partner users. You may be impacted by these changes if your organisation uses Communities or Sites to give access to external users using standard profiles.
Salesforce is disabling the API-enabled permission on all standard and cloned external profiles. This is a critical update which will be enforced at a later date.
Standard profiles are those made available by Salesforce when you first license Salesforce. Best practice is to clone standard profiles before assigning them to users, but many Salesforce customers skip that step and assign the standard profiles. If your organisation has external customer/partner users assigned to standard or cloned external profiles which leverage the Salesforce API then when the Summer ’19 critical update is activated external users will be blocked from accessing the Salesforce API (until you specifically re-enable the API enabled option in the cloned profiles).
“API enabled” is a permission available in profiles. This permission enables users to access Salesforce API. The Summer ‘19 release includes a critical update which when activated will disable this permission in all external profiles. External profiles include Customer Community profile, Customer Community plus profile, Portal User profile, Partner profile, External Identity login profile and Partner Community profile.
By making this change Salesforce are forcing customers to make deliberate choices about whether to allow API level access to external users, and which external connected apps are permitted. There are situations where an external user would need an API enabled user permission and hence soon must have a custom user profile. These include:
When this critical update in Summer ’19 is activated some of following may occur if external users remain assigned standard user profiles:
If you need to enable API access for external users (via the API access user permission) follow these steps:
Granting API access to any user inherently carries risk that users may utilise apps other than those you expect. In order to prevent this from occurring make sure connected apps are not set to “all users can self-authorise” and consider contacting Salesforce to request Client App Whitelisting be enabled.
Sharing Settings (Org Wide Defaults in classic) control the access to all standard and custom objects for all users. The sharing rules set for internal users is by default applied to external users as well unless the External Sharing Model is enabled. Currently an administrator has to manually enable the External Sharing Model then manually set the default access for external users (which inherits the internal user model to start with).
This means that if the internal sharing setting for Accounts and Contacts is public read/write or read/only then if the external sharing model is not enabled, or is enabled without changing the settings, then all external users can access all Accounts and Contacts, which would not normally be intended.
From Summer ’19 the External Sharing Model will be enabled by default and new custom objects when created will have external user access set to private. This is an enforced critical update in the Summer ’19 release.
There is an option in the Site configuration sitting behind Salesforce Communities which allows access to standard pages to be disabled. For example the home tab (/home/home.jsp) is a standard page but you may not want an external user to navigate to this link. The Allow Access to Standard Salesforce Pages setting is enabled by default. More standard pages are added to the list of standard pages in the Summer ’19 release so if you have disabled standard page access the effect is about to change.
If this has already been disabled for a community/site in your org, you should test if the newly blocked standard pages are being used by community users. If The community users are using these newly blocked standard pages and this setting is disabled, they will no longer be able to access those pages.
Salesforce issues three major seasonal releases every year – Spring, Summer and Winter. Generally the Spring release is around February, the Summer release is around June, and the Winter release is around October. Sandboxes can be upgraded to the pending release about one month before the release is imposed on Production. The exact dates for each instance will vary.
You can find about the current and pending release at https://releasenotes.docs.salesforce.com.
You can find the release schedule for the core Salesforce Sales Cloud at https://status.salesforce.com/products/Sales_Cloud/maintenances. You can narrow the results to show just your “instance” of Salesforce by entering you instance like “AP6”. You can find this out by going to Setup and expanding Company Information.
If you are concerned about the impacts of the Summer ’19 release re-check functionality in a sandbox which has been upgraded to Summer’19 before your production environment is upgraded.
You should also regularly review the critical updates and pay particular attention to the enforced activation date. At this date your org will inherit the critical update regardless, so prior to this date, activate the update in a sandbox and make sure your implementation is not impacted.
Your organisation may benefit from a Salesforce Technical Audit from Artisan. Artisan will review your configuration and code, compare this to best practice, and where there are deviations provide practical recommendations to come into alignment. Artisan can also be engaged to make those best-practice alignment changes.
Think of a technical audit as a building inspection in a construction site. It is best to do this regularly especially during the construction phase. If there are adjustments which should be made to what has been built it is less costly/painful to find that out early. Artisan can provide ongoing technical assurance/architecture services during Salesforce program delivery.
Artisan is also available to implement Salesforce for first users, assist with incremental project delivery or to remediate legacy customisation which is blocking your upgrade path to Salesforce Lightning.
© 2022 Artisan.