Spring 20 highlights
April 19, 2024
- Permission Set Groups: Greater Flexibility in Granting Permissions (Generally Available) – Permission set groups are an ideal way to consistently and reliably assign permissions to a group of users. Assign users a single permission set group instead of multiple permission sets. Permission set groups combine selected permission sets to provide all the permissions that users need for their job function. Remove individual permissions from a group with the muting permission set feature to ensure that permissions do not exceed user job functions.This change applies to Lightning Experience and Salesforce Classic.
- Group Permission Sets Based on User Job Function for Easier Assignment (Generally Available) – Now you can assign users a single permission set group instead of multiple permission sets. Permission set groups combine selected permission sets to provide all the permissions that users need for their job. Similarly, remove individual permissions from a group with the permission muting feature to ensure that users do not get permissions that are not relevant to their job functions. A new user interface helps you create and manage permission set groups.
- Track Permission Set Edits with a New Confirmation Menu – It just got easier to track bulk edits on permissions. We’ve improved readability and security so that multiple-selection permissions and any permission dependencies are summarized on a separate page. With the Permission Changes Confirmation page, you can easily identify and review all added and removed permissions before they become part of your permission ecosystem. Previewing the permission edits summary helps you better manage and maintain security control for your users and organization.
- Manage Permissions in Permission Set Groups with a Muting Permission Set (Generally Available) – A muting permission set is a handy way to increase security and ensure that only components that are required by your organization and users are accessible and, conversely, those components that shouldn’t be accessed are not available. When used along with permissions, a muting permission set gives you granular control over permissions and helps make sure you’re complying with the principle of least privilege.
- External Org-Wide Defaults Are Enabled by Default in All New Orgs – To better secure your data, the External Sharing Model is enabled by default in all Salesforce orgs created in Spring ’20 or later. External org-wide defaults let you set more restrictive levels of access for external users, instead of giving internal and external users the same default access. In these newly created orgs, external access levels are initially set to Private for all objects.
- The External Sharing Model Can No Longer Be Disabled – To better protect your Salesforce org’s data, you can no longer disable the external sharing model after it’s enabled in your org.
- Safeguard Your Data by Setting External Access Levels for the Lead and Campaign Objects (Generally Available) – You can now set external access levels for the Lead object, which was previously in beta, and the Campaign object. Select more restrictive access for external users without changing the default internal access level. The objects available for external org-wide defaults vary depending on your Salesforce org’s licenses and other settings.
- Changes to Sharing API Access – Access to sharing rules and sharing sets through the Salesforce API is available for users with the View Setup and Configuration permission. Editing sharing rules and sharing sets through the API is available for users with the Manage Sharing permission.
- Permission Changes for Queues – Access to queues through the Salesforce API is available for standard and partner users, while editing queues is available for users with the Manage Users permission.
- Authentication and Identity: Apple Sign-In, Identity Verification, and API Access Control – Enable Apple sign-in for your orgs and communities, allowing users to authenticate with their Apple ID, Face ID, or Touch ID. Enhance identity verification security by storing domain verification files for external services and enabling verification methods that are more secure than email. Restrict external user access to Salesforce APIs through connected apps that are installed in your org or community. And apply the Request Signature Methods to single logout, have extra time to approve OAuth authentication requests, and troubleshoot bridged OAuth sessions.
- Domains: Custom Domains for Sandboxes (Pilot), Salesforce Edge, Instanceless URLs, and Certificate Changes for My Domains – Test your Salesforce Sites and Communities in a sandbox using custom domains (Pilot). For customers with a My Domain, certificates are changing and you can accelerate domain requests with Salesforce Edge. Remove instance names from My Domain URLs through critical updates or sandbox refreshes.
- Salesforce Shield: Real-Time Event Monitoring Threat Detection (Beta), Event Monitoring Analytics App Improvements, and Platform Encryption for Platform Events – Use Real-Time Event Monitoring platform events to detect common threats to your org (Beta). We improved the performance of the Event Monitoring Analytics app. The legacy transaction security policy framework will be retired in Summer ’20. Shield Platform Encryption now supports Platform Events in addition to Change Data Capture Events.
- Data Protection and Privacy: Party Consent, Communication Subscription, and Contact Point Objects – Store data related to your customers’ general consent preferences and the communications that they subscribe to. You can also associate multiple email addresses or phone numbers to individuals or person accounts, and manage their preferred time and consent to be contacted.
- Other Security Changes: Guest User Record Assignment, External URL Whitelist, and Setup Enhancements – Set up a default owner for any records created by guest users in Salesforce Sites. Whitelist external URLs that users are allowed to navigate to directly. Plus, we made improvements to Session Security Level Policies and the Setup Audit Trail.
- General Setup: Custom Settings Enhancements and Improved Connections with Enhanced External Services – Protect and control who has access to custom settings. Create better connections to outside services with Enhanced External Services.
- Require Customize Application Permission for Direct Read Access to Custom Settings (Critical Update, Enforced) – Access for users without the Customize Application permission to read unprotected custom settings is revoked as part of this critical update. Using different APIs that are provided by Salesforce, users without the Customize Application permission could read unprotected custom settings. Following the “secure by default” approach, this access is revoked.
- Protect Custom Settings in Developer and Scratch Orgs – The Visibility field is now only available in developer or scratch orgs, where managed packages can be created. When you create a custom setting, the package type and the Visibility field determine whether the custom setting is public or private. You can only create protected custom settings in a developer or scratch org that are then deployed in a managed package. In addition, the Visibility field must be set to protected.
- Control Who Gets Read Access to Custom Settings – You can now control the access of custom settings at a granular level by granting direct Read access to specific custom settings through profiles and permission sets.
- Make More Connections the Enhanced External Services Way (Generally Available) – Enhanced External Services is generally available and enabled by default. It’s easy to use, and provides more ways to create and connect to outside services. Now, when you register a service, you get support for more complex OpenAPI 2.0 schema, nested object types, and send parameters as headers within the HTTP requests.
- Require Permission to View Record Names in Lookup Fields (Critical Update) – To better protect your Salesforce org’s data, we restrict who can view record names in lookup fields. Beginning in Summer ’20, users must have read access to these records or the View All Lookup Record Names permission to view this data. This critical update also applies to system fields, such as Created By and Last Modified By.
- Secure Your Sandbox Data with Salesforce Data Mask – Salesforce Data Mask is a powerful new data security resource for Salesforce admins and developers. Instead of manually securing data and access for sandbox orgs, admins can use Data Mask to automatically mask the data in a sandbox.
- Permission Changes for Administrator Tasks – To access permissions or permission set groups, users must have the View Setup and Configuration permission or the equivalent permissions to manage permission sets or users, including Manage Session Permission Set Activations, Manage Users, and Assign Permission Sets.
- Changes to Managing User Roles and Preferences – Access to user roles is available for users with the View Roles and Role Hierarchy permission. Editing user roles is available for users with the Manage Roles permission. Access to UserPreference records of other users in the SOAP API is available for users with the View All Data or Manage Users permission, but all users can access their own UserPreference record.