Permissions
Create permission set and permission set group assignments with an expiration date, and review the release update for this change. And monitor the assignment of critical user permissions by creating transaction security policies.
Enable Stronger Protection for Your Users’ Personal Information (Release Update)
Enable Enhanced Personal Information Management to prevent external users, such as portal or community users, from accessing other users’ personal information. This feature, which replaces the Hide Personal Information setting, secures more personal identifiable information (PII) user record fields. You can also decide which custom and standard user fields are considered PII. This update was first available in Spring ’22.
Where: This change applies to Lightning Experience in Enterprise, Performance, Unlimited, and Developer editions.
When: Salesforce enforces this update in Winter ’23. To get the major release upgrade date for your instance, go to Trust Status, search for your instance, and click the maintenance tab.
How: From Setup, in the Quick Find box, enter User Management Settings, and then select User Management Settings. If Hide Personal Information is enabled, deselect it. Enable Enhanced Personal Information Management. To customize the user fields that are concealed, add them to a field set.
To review this update, from Setup, in the Quick Find box, enter Release Updates, and then select Release Updates. For Enable Stronger Protection for Your Users’ Personal Information, follow the testing and activation steps.
Build More Flexible Restriction and Scoping Rules with Single Picklists
To restrict record access based on a custom picklist value, add a single picklist to your restriction or scoping rule. Single picklists are supported in record criteria, but multi-select picklists aren’t.
Where: Restriction rules are available in Lightning Experience in Enterprise, Performance, Unlimited, and Developer editions. Scoping rules are available in Lightning Experience to customers using Unlimited or Performance Edition with Signature Support or Program Architect or Technical Account Manager professional services.
How: To use a picklist in your rule’s record criteria, navigate to Object Manager in Setup and select an object. Click Restriction Rules or Scoping Rules. Name and describe the rule, and then activate it. Select a picklist as the type field in record criteria, and choose a picklist value to determine the records that the rule applies to.
Preserve User Access to Personal Information Fields
To ensure that the appropriate users can access personally identifiable information (PII) in Summer ’22, update those users’ permissions. Users with broad permissions such as View All Data and View All Users can no longer view personal information. To give users access to personal information, assign the View Concealed Field Data permission, which replaces the View User Records with PII permission.
Where: This change applies to Lightning Experience in Enterprise, Performance, Unlimited, and Developer editions.
How: To maintain a user’s access, including work.com users, to personal information fields, assign the user to a permission set in Setup that grants the user the View Concealed Field Data permission.
Adjust Restriction Rules Permissions
To standardize the way that permissions work, users with the View All or Modify All permission can now access records that a restriction rule applies to. The View All or Modify All permissions now work just like the Modify All Data and View All Data permissions. Restriction rules no longer block access to records for users assigned View All or Modify All for an object.
Where: Restriction rules are available in Lightning Experience in Enterprise, Performance, Unlimited, and Developer editions.
How: Find the View All or Modify All permissions in Object Permissions in Permission Sets.
Create and Edit Records That a Restriction Rule Applies To
Restriction rules no longer prevent users from creating or editing a record. Users can create a record that a restriction rule subsequently blocks their access to. A user can edit a record so that a restriction rule blocks subsequent access to the record based on the value they changed.
Where: Restriction rules are available in Lightning Experience in Enterprise, Performance, Unlimited, and Developer editions.
Why: Because restriction rules no longer apply when a user creates a record, you can observe these behaviors.
- Restriction rules no longer prevent a user from creating a record. Users can create a record even if a restriction rule’s criteria blocks their access to the record after they create it.
- Editing a field on a record can cause a restriction rule to block access to that record. Based on the edited value, the user can no longer view, edit, or delete the record.
How: Create and manage restriction rules by navigating to a supported object in the Object Manager.
Control Access to External Object Records with Restriction Rules
Restriction rules allow certain users to access only the records that are essential to their work. To apply this layer of security to data that’s stored outside your Salesforce org, set a restriction rule on external object records.
Where: Restriction rules are available in Lightning Experience in Enterprise, Performance, Unlimited, and Developer editions. External objects are available with Salesforce Connect and Files Connect.
How: To create and manage restriction rules for external object records, add a restriction rule from the External Data Sources page in Setup. Only external objects created using the Salesforce Connect: OData 2.0, OData 4.0, and Cross-Org adapters support restriction rules.
External objects don’t appear in Object Manager. To navigate to an external object, from Setup, in the Quick Find box, enter External Data Sources, and then select External Data Sources. Select an external object from the list view on this page. Or find external objects in the Most Recently Used list in Setup.
Admins are responsible for ensuring that rules they create on external objects don’t negatively impact performance in Salesforce or in the external system.
Sharing
Grant secure access to external objects with restriction rules. Restriction rules no longer apply to creating records. Scoping and restriction rules support single picklists in record criteria and user criteria. Plus, a more granular permission governs access to users’ personally identifiable information (PII) when admins secure it using the Enhanced Personal Information Management setting.
General Enhancements
MFA Requirement Is in Effect and Enforcement Is Coming. The requirement to use multi-factor authentication (MFA) when accessing Salesforce products went into effect on February 1, 2022. All users are now required to use MFA when they log in to your Salesforce org, whether they’re logging in directly with a username and password or using SSO. If you haven’t finished rolling out MFA, your users can continue logging in as they do today. But keep in mind that Salesforce is automatically enabling and enforcing MFA in the future. To avoid disruptions to your business when these milestones go into effect, and to protect your valuable data, we strongly recommend enabling MFA yourself as soon as possible
Where: This change applies to Lightning Experience, Salesforce Classic, and all Salesforce mobile apps in all editions.
When: As of February 1, 2022, Salesforce customers are contractually required to use MFA when accessing Salesforce products, per the Salesforce Trust and Compliance Documentation. In the future, Salesforce is automatically enabling and enforcing MFA for all orgs. To monitor the projected dates for the auto-enablement and enforcement milestones, see the MFA Enforcement Roadmap.
How: To implement and roll out MFA on your own:
- Check out the Multi-Factor Authentication Assistant. In Lightning Experience, from Setup, in the Quick Find box, enter MFA, and then select Multi-Factor Authentication Assistant.
- Get customizable templates for rollout planning and change management by downloading the MFA Rollout Pack.
- Make sure that your implementation satisfies the terms of the MFA requirement with the MFA Requirement Checker.
Spring 20 highlights
- 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.