Removal of Guest User Access to Recognition Badges in Experience Builder Sites (Release Update)
To make sure that recognition badges aren’t visible to guest users unintentionally, the default rules now allow only authenticated users to see them. But you can turn off the default setting if you prefer. This update was first made available in Winter ’22 and is enforced in Winter ’22.
Where: This change applies to Aura sites accessed through Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.
When: This update was first available in Winter ’22 and is enforced in Winter ’22. To get the major release upgrade date for your instance, go to Trust Status, search for your instance, and click the maintenance tab.
How: To turn off Hide badges from guest users in Experience Builder sites, go to Setup>Feature Settings>Digital Experiences>Settings.
Bid Farewell to Run Flows for Guest Users
The Run Flows permission for the Guest User and Experience Cloud External User profiles is no longer available in new orgs, starting in Winter ’22. Without the Run Flows permission, you’re free to use the more granular permission structure embedded in Flows and give your users the detailed access they need. Run Flows will be removed from all orgs in the Summer ’22 release. To avoid future access issues, we recommend updating your existing sites to the new permission structure before the Summer ’22 release.
Where: This change applies to Aura, LWR, and Visualforce sites accessed through Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.
Bid Farewell to Run Flows for Guest Users (salesforce.com)
Create Sharing Rules to Retain and Control Guest Users’ Product Access (Release Update)
To better protect your Salesforce data, this update changes how unauthenticated guest access to product records is controlled. To prevent guest users from losing access to products, create and test guest user sharing rules. The Product org-wide sharing default for external users is no longer applied to guest users, and guest user access is set to Private. This setting can’t be changed. This update was first made available in Winter ’22.
Where: This change applies to Lightning Experience and Salesforce Classic in Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions.
When: The setting Secure guest user record access isn’t applied to products in Winter ’22. Salesforce will enforce this update in Spring ’22.
Hide More Personal Information Fields
Prevent external users, such as portal or partner users, from viewing personal information in your user records. Now when you apply the Enhanced Personal Information Management setting, Salesforce blocks view access to 20 fields that are considered personal information. This setting is also more flexible than the Hide Personal Information setting. To implement this setting, in User Management Settings, add or remove the PersonalInfo compliance category for any field.
Where: This change applies to Lightning Experience in Enterprise, Performance, Unlimited, and Developer editions.
Hide More Personal Information Fields (salesforce.com)
Security and Sharing
Hide more personal information fields with a new user setting, retain guest users’ access to products, and give more granular access to flows.
- Hide More Personal Information Fields
Prevent external users, such as portal or partner users, from viewing personal information in your user records. Now when you apply the Enhanced Personal Information Management setting, Salesforce blocks view access to 20 fields that are considered personal information. This setting is also more flexible than the Hide Personal Information setting. To implement this setting, in User Management Settings, add or remove the PersonalInfo compliance category for any field. - Create Sharing Rules to Retain and Control Guest Users’ Product Access (Release Update)
To better protect your Salesforce data, this update changes how unauthenticated guest access to product records is controlled. To prevent guest users from losing access to products, create and test guest user sharing rules. The Product org-wide sharing default for external users is no longer applied to guest users, and guest user access is set to Private. This setting can’t be changed. This update was first made available in Winter ’22. - Bid Farewell to Run Flows for Guest Users
The Run Flows permission for the Guest User and Experience Cloud External User profiles is no longer available in new orgs, starting in Winter ’22. Without the Run Flows permission, you’re free to use the more granular permission structure embedded in Flows and give your users the detailed access they need. Run Flows will be removed from all orgs in the Summer ’22 release. To avoid future access issues, we recommend updating your existing sites to the new permission structure before the Summer ’22 release. - Removal of Guest User Access to Recognition Badges in Experience Builder Sites (Release Update)
To make sure that recognition badges aren’t visible to guest users unintentionally, the default rules now allow only authenticated users to see them. But you can turn off the default setting if you prefer. This update was first made available in Winter ’22 and is enforced in Winter ’22.
Security and Sharing (salesforce.com)
Grant Access to the DeveloperName Field to Users Who Require It
The DeveloperName field has new permission requirements for multiple Salesforce objects and types across various APIs. Following the Winter ’22 release, some users can lose access to the DeveloperName field on objects that they typically interact with. To view, group, sort, or filter the DeveloperName field on affected API objects, you must have View Setup and Configuration OR View DeveloperName permission.
Where: This change applies to all editions.
How: Restore access by giving users the View Setup and Configuration OR View DeveloperName permission via a profile or permission set. For a list of affected objects and types, see the related knowledge article.
Grant Access to the DeveloperName Field to Users Who Require It (salesforce.com)
Manage Assignment Expiration in Permission Sets and Permission Set Groups (Beta)
You can now view and update current assignment expirations for your permission sets and your permission set groups. Previously, to update assignment expirations, you recreated them with the correct expiration date.
Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
Why: Suppose a sales manager wants consultants to evaluate the language used in sales contracts. You give the consultants access to the contracts object and other permissions via a permission set group so that they can perform their work. The project has an end date, so you don’t want contractors to access sales contracts after that date. Set the expiration date for the permission set group when you assign it to users. If the project end is extended, edit the expiration date for the permission set group to the new date.
How: Enable Permission Set Group Assignments with Expiration Dates (Beta) in User Management Settings. Then from either the Permission Set Group or Permission Set page, click Manage Assignment Expiration. On the Current Assignments page, you can view a list of the users that are assigned to the permission set or the permission set group. To create a user assignment, click Add Assignment. To modify the expiration date of existing assignments, click 
. To remove an assignment, click 
.
Manage Assignment Expiration in Permission Sets and Permission Set Groups (Beta) (salesforce.com)
Create Custom Profiles from Scratch via the SOAP API
It’s easier to configure custom profiles to have the permissions you need. Use the Profile SOAP API object to create custom profiles that start without any permissions enabled. Previously, to create a custom profile, you cloned an existing profile in Setup and then removed permissions that you didn’t want the assigned users to have. The Profile Metadata API type functions as before.
Where: This change applies to Lightning Experience and Salesforce Classic in Professional, Enterprise, Performance, Unlimited, and Developer editions.
How: Use the create() call on the Profile SOAP API object and specify the Description, Name, and UserLicenseId fields. You can enable permissions using the API or, after the profile is created, on the profile’s page in Setup. Required permissions for the profile’s user license are automatically enabled.
Create Custom Profiles from Scratch via the SOAP API (salesforce.com)
Grant Access Based on Activated User Sessions for Permission Set Groups
To grant your users only the access that they need when they need it, combine the management power of permission set groups with session-based access control. Create a session-based permission set group to grant access to permission sets during an activated user session. Previously, you created individual session-based permission sets, but now you can set sessions at the permission set group level as well.
Where: This change applies to Lightning Experience and Salesforce Classic in Professional, Enterprise, Performance, Unlimited, and Developer editions.
Why: For example, you have a customized Salesforce app that accesses confidential information. For security reasons, you want to limit user access to a predetermined length of time. Some users, such as a team manager, require expanded access for the same length of time. You can create a permission set group that includes the different permission sets required for the confidential access. You can create a flow or use the API to create custom logic to activate the session-based permission set group. In this example, the session-based permission set group activates only when the manager-level users authenticate into your environment using a token. When the token expires, the users must reauthenticate to access the application again.
How: To create a session-based permission set group, select Session Activation Required on the Permission Set Group create page. Then, activate the session for the permission set group using a flow or the SessionPermSetActivation SOAP API object.
Grant Access Based on Activated User Sessions for Permission Set Groups (salesforce.com)
Profiles and Permissions
Get the benefits of expanded profile and permission management. Use the power of permission set groups to configure session-based access control. Create custom profiles using the API instead of cloning existing profiles.
- Grant Access Based on Activated User Sessions for Permission Set Groups
To grant your users only the access that they need when they need it, combine the management power of permission set groups with session-based access control. Create a session-based permission set group to grant access to permission sets during an activated user session. Previously, you created individual session-based permission sets, but now you can set sessions at the permission set group level as well. - Create Custom Profiles from Scratch via the SOAP API
It’s easier to configure custom profiles to have the permissions you need. Use the Profile SOAP API object to create custom profiles that start without any permissions enabled. Previously, to create a custom profile, you cloned an existing profile in Setup and then removed permissions that you didn’t want the assigned users to have. The Profile Metadata API type functions as before. - Manage Assignment Expiration in Permission Sets and Permission Set Groups (Beta)
You can now view and update current assignment expirations for your permission sets and your permission set groups. Previously, to update assignment expirations, you recreated them with the correct expiration date. - Grant Access to the DeveloperName Field to Users Who Require It
The DeveloperName field has new permission requirements for multiple Salesforce objects and types across various APIs. Following the Winter ’22 release, some users can lose access to the DeveloperName field on objects that they typically interact with. To view, group, sort, or filter the DeveloperName field on affected API objects, you must have View Setup and Configuration OR View DeveloperName permission.
Profiles and Permissions (salesforce.com)