Selecting between 1GP Managed, 2GP Managed, 2GP Unlocked Package

Question

My company needs to be publish a set of Salesforce packages that enable two way integration between Salesforce and a proprietary student registration system. These packages will be installed by multiple clients. The packages include the following metadata:

• custom Contact fields
• new custom objects
• a custom settings type
• Apex triggers and classes

Upon package installation, ideally we need to create the following metadata:

• a Chatter group
• a custom settings object
• a Salesforce profile with ability to view (but not edit) a subset of the new custom Contact fields that were added.

I'm trying to decide whether 1GP managed, 2GP managed or 2GP unlocked package would be the most appropriate packaging mechanism based on the requirements below:

• The least amount of manual setup steps post-package-installation
• The ability to upgrade packages

My questions are as follows:

• To create a Chatter group and a custom settings object automatically -- which are editable afterwards -- post-package installation, the ideal (only?) way of doing this would be via a post-installation script, and managed packages (both 1GP and 2GP) support this but unlocked packages do not. Is that correct?
• Is it correct that the following data can all be included as package contents of both 2GP unlocked and managed packages? ** Creation of Remote site settings ** Creating a Salesforce profile ** Changing field visibility for the created Salesforce profile I'm basing this on the fact that I see changes appear in the "diff" when I run sfdx force:source:status after creating/making the above changes.

Thank you.

Answer 1

From my perspective, I would say that 1GPs are now replaced by 2GP and should not be adopted for new package development. That said, there are a small number of metadata types still not supported by 2GPs that are covered in 1GP (aka "classic packaging"). This is outlined in the metadata coverage report (you can select the required API version to see the differences across versions). Use this to discover what you can and cannot package in the different ways.

I would also say, don't use custom settings, but instead use custom metadata types - by adopting the latter you can actually include custom metadata type instances/records as part of your package directly without the need to create instances in a post-installation script. You have the choice to make the instances/records protected (only accessible in your package and upgradeable) or unprotected (exposed in the subscriber org, but not upgradeable) depending on who is to manage these "settings".

Chatter support in packages is low, regardless of generation, as per the metadata coverage report; you are going to need to simply try out different approaches based on your need.