• Permission Set Groups: Assign users a single permission set group instead of multiple permission sets.
• Install Even More Custom Objects in Your Org: raised the total hard limit for custom objects in an org to 3,000 (up from 2,500 in the previous release) so that you can install more custom objects from packages.
• Check a Field’s References and Find Reports Using It (Generally Available): With the click of a button, view the references to a custom field before you edit it, such as references in a formula, layout, or Apex class.
• Secure Guest Users’ Sharing Settings: When you enable the Secure guest user record access setting, you set guest users’ org-wide defaults to Private for all objects. This setting also restricts the way you can share records with guest users and lets you create new guest user sharing rules.
• Safeguard Your Data by Setting External Access Levels for More Standard Objects (Generally Available): You can now set external access levels for many more standard objects. Select more restrictive access for external users without changing the default access level for internal users.
• Keep Sharing Records When Migrating to Enterprise Territory Management: If you’re migrating to Enterprise Territory Management, you can keep your original territory sharing records so that your sales team can continue working.

Well its been a big release. Better control over external user access to data through controlling the org wide defaults on external objects. Permission set groups in Beta. Understand where a field is used throughout your org. They upped the limit from 2500 to 3000 custom objects and the reporting around custom object usage. Improved domain name setting, API monitoring, Sharing settings and much much more.

With the click of a button, view the references to a custom field before you edit it, such as references in a formula, layout, or Apex class. On a custom field’s detail page, click Where is this used? to see where a field is used and where changes to the field appear. Use this information to communicate changes to others who use the field in a formula or other context. In this release, we added support for reports.

Where: This change applies to Lightning Experience and Salesforce Classic in Professional, Enterprise, Performance, and Unlimited editions.

Who: Admins with the View Setup permission can check where a custom field is used.

The list can include these references.

• Validation rule
• Layout
• Formula field
• Visualforce page
• Apex class
• Apex trigger
• Email template (Salesforce Classic, text based)
• Field set
• Flow (query)
• Lightning component markup (attr)
• Process Builder (criteria)
• URL button (formula)
• Lightning page (related list single)
• Lookup filter (lookup and master detail)
• Reports (column

Click a reference label to view the settings for the layout, formula, or other reference. Reference labels link to more information only if there is a known settings page for the reference. For example, a report name links to the report settings. But, a criteria formula created within a flow does not link to the flow settings.

Within a subscriber org, references in a managed package aren’t included in the list of results. For example, you have a number field referenced in a formula. If you add the field to a package and install the package in a subscriber org, the subscriber org’s field reference detail page doesn’t show that this number field is referenced in a formula field.

However, new references created after installing the managed package in the subscriber org do appear. For example, after you install the managed package and you add the number field to another formula in the subscriber org, the new reference appears.

https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_fields_where_ga.htm&release=222&type=5

The Allow Access to Customized Actions permission is no longer required to access customized actions.

Where: This change applies to Lightning Experience in Group, Professional, Enterprise, Performance, Unlimited, Contact Manager, and Developer editions.

https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_general_actions_userperm_not_required.htm&release=222&type=5

If you’re migrating to Enterprise Territory Management, you can keep your original territory sharing records so that your sales team can continue working. After the migration is complete, use the SharingSettings Metadata API type to delete these records.

Where: This change applies to Lightning Experience and Salesforce Classic in Performance and Developer editions and in Enterprise and Unlimited editions with the Sales Cloud.

https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_sharing_enterprise_territory.htm&release=222&type=5

You can now assign different internal and external access levels for leads. Use external org-wide defaults to set a more restrictive access level for external users without changing the access that internal users have. 

Where: This change applies to Lightning Experience and Salesforce Classic in Professional, Enterprise, Performance, Unlimited, and Developer editions. 

How: To set the external access level, from Setup, enter Sharing Settings in the Quick Find box, then select Sharing Settings. Under Organization-Wide Defaults, edit the default external access for Lead. 

https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_sharing_lead_beta.htm&release=222&type=5

You can now set external access levels for many more standard objects. Select more restrictive access for external users without changing the default access level for internal users. The objects available for external org-wide defaults vary depending on your org’s licenses and other settings.

Where: This change applies to Lightning Experience and Salesforce Classic in Professional, Enterprise, Performance, Unlimited, and Developer editions.

How: To set external org-wide defaults, from Setup, enter Sharing Settings in the Quick Find box, then select Sharing Settings. Under Organization-Wide Defaults, edit the default external access.

https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_sharing_owd_ga.htm&release=222&type=5

When you enable the Secure guest user record access setting, you set guest users’ org-wide defaults to Private for all objects. This setting also restricts the way you can share records with guest users and lets you create new guest user sharing rules.

Where: This change applies to all communities accessed through Lightning Experience and Salesforce Classic in Essentials, Enterprise, Performance, Unlimited, and Developer editions.

https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_sharing_guest_user.htm&release=222&type=5

We did it again: We raised the total hard limit for custom objects in an org to 3,000 (up from 2,500 in the previous release) so that you can install more custom objects from packages.

Where: This change applies to Lightning Experience and Salesforce Classic in all editions.

Why: Why not? You can do more with more objects. Each Salesforce edition has a limit on the number of custom objects that you can create in your org. Beyond the edition limit, a hard limit governs how many custom objects you can install from managed packages, such as apps publicly posted on AppExchange. The new 3,000 total limit includes the maximum number of custom objects created and installed in your org. For example, in Unlimited Edition, you can create up to 2,000 custom objects in your org. On top of that limit, you can also install up to 1,000 custom objects from managed packages. If your org is approaching the 3,000 total limit, we recommend that you hard delete or erase custom objects that you no longer need.

https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_objects_limit_increase.htm&release=222&type=5