First-Generation Managed Packaging Developer Guide

First-Generation Managed Packages
Why Switch to Second-Generation Managed Packaging?
Move to 2GP: Migrate Your Managed Packages with Ease
Register a Namespace for a First-Generation Managed Package
Create a First-Generation Managed Package Using a UI
Create a First-Generation Managed Package using Salesforce DX
Components Available in First-Generation Managed Packages
Behavior of Specific Metadata in First-Generation Managed Packages
Package and Test Your First-Generation Managed Package
Update Your First-Generation Managed Package
Publish Upgrades to First-Generation Managed Packages
Plan the Release of First-Generation Managed Packages
Remove Components from First-Generation Managed Packages
Delete Components from First-Generation Managed Packages
Modifying Custom Fields after a Package Is Released
Manage Versions of First-Generation Managed Packages
View Unused Components in a Managed Package
Push Package Upgrades to Subscribers
Push Upgrades
Push Upgrade Best Practices
Assign Access to New and Changed Features in First- and Second-Generation Managed Packages
Sample Post Install Script for a Push Upgrade for First- and Second-Generation Managed Packages
Scheduling Push Upgrades
Enable a Package Subscriber to Restrict Push Upgrades
Manage Licenses for Managed Packages
Manage Features in First-Generation Managed Packages
AppExchange App Analytics for First-Generation Managed Packages
Developing and Distributing Unmanaged Packages
PDF

Enable a Package Subscriber to Restrict Push Upgrades

In certain scenarios, a Salesforce customer may require the ability to block push upgrades of managed packages that they have installed in their org. Customized push upgrades let Salesforce Partners give customers the ability to restrict push upgrades to a specific customer org for a specific package.
Setting up customized push upgrades requires both the Salesforce Partner and Salesforce Customer to complete specific enablement steps.
  1. The Salesforce Partner enables customized push upgrades for a package installed in the customer org.
    1. As the Salesforce Partner, log in to either your 1GP packaging org, or your Dev Hub org (for managed 2GP packages) using the system administrator account.
    2. Click the gear icon and select Developer Console.
    3. In the Developer Console, select Debug, and then select Open Execute Anonymous Window.
    4. Enter the following code, but remember to replace the packageID (starts with 033) and subscriberOrgID (starts with 00D) text for the package ID and customer org you’re enabling. 
      1String pucId1 = PushUpgradeCustomizationRepository.create('packageID', 'subscriberOrgID', true);
2System.debug('pucId1 =' + pucId1);

      Optionally, you can set the ability to block push upgrades to expire after a certain number of days. This example sets customized push upgrades to expire after 90 days.

      1String pucId1 = PushUpgradeCustomizationRepository.create('packageID', 'subscriberOrgID', true, 90);
2System.debug('pucId1 =' + pucId1);

      If the customer wants to block push upgrades to multiple production orgs, you must specify each org ID. Here’s an example of how to enable customized push upgrades for more than one org.

      1String pucId1 = PushUpgradeCustomizationRepository.create('packageID', 'subscriberOrgID', true);
2System.debug('pucId1 =' + pucId1);
3      
4String pucId2 = PushUpgradeCustomizationRepository.create('packageID', 'subscriberOrgID', true);
5System.debug('pucId2 =' + pucId2);
    5. Click Open Log and then click Execute.
    6. Click the Debug Only checkbox and verify that the push upgrade customization record was created.
      The record looks something like: 11:09:15:814 USER_DEBUG [2]|DEBUG|pucId1 =12COK000000000B
    7. Contact the Salesforce Customer and let them know that customized push upgrades is enabled on your end.

    Sandbox orgs automatically get the ability to block push upgrades if the parent production org has been granted the ability to block push upgrades by the Salesforce Partner.

    Note

  2. After the Salesforce Partner enables customized push upgrades, the Salesforce Customer blocks push upgrades from Setup in the customer org.
    1. As the Salesforce Customer, log in to your org.
    2. From Setup, enter Installed Packages in the Quick Find box, and then select Installed Packages.
    3. Select the package that you’ve requested to block push upgrades, and then select Block Push Upgrades.
    4. Verify that the Push upgrades are now blocked checkbox is selected.

It’s not possible to block push upgrades on a patch version of a package. If the customer has a patch version installed, they must upgrade to a non-patch version of the package before they can block push upgrades.

Note

Salesforce Customers can resume push upgrades at any time by selecting the Allow Push Upgrades button. While the block is enabled, package upgrades can only be installed manually.

Salesforce Partners can view and manage existing customized push upgrades by using the PushUpgradeCustomizationRepository Apex Class. If you enabled customized push upgrades for a subscriber with an expiration, you can update the expiration days by following Step 1. For Step 1d, use either the setExpirationDaysForId or setExpirationDaysForIndex method to update the expiration days. This example updates the expiration days to 100 days.

1PushUpgradeCustomizationRepository.setExpirationDaysForIndex('packageID', 'subscriberOrgID', 100);
2System.debug('Expiration days updated successfully');

This example updates the expiration days for the PushUpgradeCustomization record ID 12Cxx000000ABCDEF1 to 120 days.

1PushUpgradeCustomizationRepository.setExpirationDaysForId('12Cxx000000ABCDEF1', 120);
2System.debug('Expiration days updated successfully');

If the customer has blocked push upgrades from the subscriber org, it’s not possible to decrease the number of expiration days.

Note