Explore the Subscriber Experience of Packages
Learning Objectives
After completing this unit, you’ll be able to:
- Describe the subscriber’s experience of package installation and setup.
- Explain a patch version’s uses.
Subscriber Experience of Packages
So what happens after you publish your package? Let’s take a look.
D’Angelo is the Salesforce admin for DreamHouse Realty. He wants to find an expense management app to make it easier for the employees at his company to submit their expense reports. And ideally, he wants an app to integrate with the data in their Salesforce org.
D’Angelo searches on AppExchange for an app that meets his criteria. He finds the expense manager app Get Cloudy created.
On the AppExchange listing, D’Angelo sees that this app requires that Multiple Currencies is enabled in his org. The AppExchange listing includes a link to a preinstallation guide. D’Angelo gets the guide and follows the preinstallation steps to enable Multiple Currencies, before installing the expense manager app.
Now that D’Angelo is ready to install the app, he clicks the Get It Now button on the AppExchange listing. The package installer requires D’Angelo to choose whether he wants to install the app in a production or sandbox environment, and which types of users in his org can access the app as soon as it’s installed. He must choose from the following settings.
- Install for Admins Only
- Install for All Users
- Install for Specific Profiles
D’Angelo chooses to install the package only for admins, because he plans to use permission sets to ensure that each user has the right level of access and permissions when using the app. He installs the package in a sandbox org, so that he and the pilot participants he’s recruited can try the app before rolling it out to all employees.
After D’Angelo installs the package, he opens Setup in his org, and assigns the package license and permission sets to users.
D’Angelo runs through the app, and likes what he sees, but wants to tweak some things, like the page layouts, to better match the standards in his org. D’Angelo makes his changes, and releases the app to his users.
How Much Can a Subscriber Customize Your App?
Each metadata component that you include in a managed 2GP package has certain rules that determine its behavior in a subscriber org. These rules determine whether or not you, or the subscriber, can make changes to or remove components after the package version is installed.
These rules let you enhance your package without overwriting your subscriber’s customizations. For example, if your subscribers customize your page layouts, their changes persist after package upgrades. But many components can only be edited by you, the developer. This is a core benefit of both managed 1GP and 2GP packages.
Upgrading a Package Version
Customers like D’Angelo have installed your package. Yippee! But you’ve discovered there’s a behavior in your app that’s unexpected, and you want to fix it and push it out to customers. How do you do that?
Or what do you do if you’ve added some spiffy new features? You want to give your customers the option to move to the new version or not. How do you do that?
Let’s hear it for package upgrades!
When you’re ready to release a new package version, you can either push the upgrade out to existing subscribers, or let subscribers decide when to upgrade to the next version.
Sometimes you’ll want to use a patch version to upgrade your package. Patch versions fix small issues with your package without introducing major feature changes. By using a patch version, subscribers who are using an older version of your package can pick up your bug fix by installing the patch version without being forced to upgrade to a new major package version. For example, if your latest released package version is 1.4.0.0, a customer who’s still on version 1.2.0.0 could receive an important bug fix if you create patch version 1.2.1.0.
To ensure seamless upgrades, patch versions are restrictive in terms of what changes you can introduce in them. For example, you can’t add new metadata in a patch version.
As you may recall, package versions follow a major.minor.patch.build number format. Any package version number that contains a non-zero patch number is a patch version. For example, 1.1.2.5.
Managed 2GP supports package upgrades, but package downgrades aren’t supported. Your customers can upgrade from version 1.3.0 to 1.3.2, but they can’t install an older version (1.3.0) on top of a newer version (1.3.2).
Congratulations! You’ve completed the Second-Generation Managed Packages module. It’s time to take the next step and start developing your first managed 2GP. To ask questions of and collaborate with other Salesforce Partners, join the Partner Community.
Resources
- Second-Generation Managed Packaging Developer Guide: Push a Package Upgrade
- Second-Generation Managed Packaging Developer Guide: Create a Patch Version
- Salesforce Partner Community: Managed Packages group (Sign-in required)