Prior to the change, customers with Lightning communities could use Lightning components (including record home, list view, global search, lookup, etc.) or Lightning Data Service to allow their guest, community and portal users to access a range of Salesforce standard objects and custom objects.
Standard Objects:
After this update, guest, portal and community users who previously could access Salesforce objects using Lightning components or Lightning Data Service can now access only a limited list.
Custom Objects:
Depending upon a customer’s settings, access to all custom object types may have been allowed for guest, portal and community user profiles. After the update, these users will not have access to the following custom object types:
If you face issues after this change, update your implementation using custom Lightning components and Apex controllers.
Prior to the change, unless prevented by a customer’s settings, guest and portal users could access Salesforce objects that didn’t have object permissions, org preferences, user permissions or preferences that control visibility. These were primarily standard objects in the enterprise or partner API.
After this update, guest and portal users who could previously access the standard objects in the enterprise or partner API without org controls will only be able to access a subset. This change affects standard objects only, and doesn’t affect custom, external, or big objects.
Salesforce has disabled the API-enabled permission on all standard external profiles and cloned external profiles of the following license types (API names in parentheses):
We strongly recommend that all customers review the external profiles in their org to determine if any require the API-enabled permission for their use cases. If your users still need the permission, clone the standard profile and select the API-enabled permission. The customer must reassign the users to the new cloned profile, and add the profile to the correct community memberships. You can use Dataloader or Workbench to mass reassign users, or create a permission set with the API enabled permission and assign it to the users who need it.
We strongly recommend that all customers review the external profiles in their org to determine if any require the API-enabled permission for their use cases. If not, we recommend turning off the API-enabled permission. Should you decide that only a subset of your users need the API-enabled permission, you can create two profiles, one with the permission enabled, and one without. Alternatively, use a permission set to assign the permission to the users that need it.
For customers having cloned external profiles with the API-enabled permission turned on, please note that the API-enabled permission allows external applications or connectors to use the API to authenticate or access Salesforce data.
Please review the cloned external profiles in your org and ensure this is necessary for your business needs. If not, we recommend turning off the API-enabled permission.
We suggest you conduct a comprehensive review of your internal and external org-wide sharing defaults for Community, portal, and guest users, and set the most restrictive authorization rules appropriate for your business needs. In addition, we recommend restricting access to your connected apps and API data management tools.
More information on recommended sharing settings in Communities can be found in this Help topic: Sharing CRM Data in a Portal or Community.
If you have questions regarding your community or portal users, please contact Support by logging a case via Salesforce Help.
000384887

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.