Second-Generation Managed Packaging Developer Guide

Second-Generation Managed Packages
What’s a Second-Generation Managed Package?
Set Up Your Development Environment
Before You Create Second-Generation Managed Packages
Scratch Orgs and Package Development
Workflow for Second-Generation Managed Packages
Components Available in Second-Generation Managed Packages
Behavior of Specific Metadata in Second-Generation Managed Packages
Develop Second-Generation Managed Packages
Install and Uninstall Second-Generation Managed Packages
Prepare to Distribute Your Second-Generation Managed Package
Push a Package Upgrade for Second-Generation Managed Packages
Schedule a Push Upgrade Using CLI
Schedule a Push Upgrade Using SOAP API for First- and Second-Generation Managed Packages
Enable a Package Subscriber to Restrict Push Upgrades
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
Push Upgrade Best Practices
Advanced Features for Second-Generation Managed Packages
Best Practices for Second-Generation Managed Packages
Manage Licenses for Managed Packages
Manage Features in Second-Generation Managed Packages
Get Started with AppExchange App Analytics
Gaps Between First-Generation and Second-Generation Managed Packaging
PDF

Newer Version Available

This content describes an older version of this product. View Latest

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);

      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 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.

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.

Note these considerations for customized push upgrades.
  • If your package is a managed 2GP and has customized push upgrades enabled, and you then transfer the ownership of the managed 2GP from one Dev Hub to another, the new Dev Hub won’t retain the required permissions. In addition, the PushUpgradeCustomizationRepository records for blocking push upgrades won’t be retained. To continue using customized push upgrades with the new Dev Hub org, repeat Steps 1 and 2.
  • 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.