The question relates to some new API 51 objects that allow second generation packaging push upgrades to be scheduled.

Running this script in our Partner Business Org (PBO):

List<String> names = new List<String>(Schema.getGlobalDescribe().keySet());
List<String> filteredNames = new List<String>();
for (String name : names) {
    if (name.contains('package')) filteredNames.add(name);
System.debug('>>> ' + String.join(filteredNames, ', '));

produces this list (LMA object references replaced by ...) which includes the objects I need to schedule 2GP push requests:

metadatapackage, metadatapackageversion, packagelicense, packagepusherror, packagepushjob, packagepushrequest, packagesubscriber, ..., userpackagelicense

but the same code in a basic scratch org produces this list:

packagelicense, userpackagelicense

What do I need to do to have e.g. PackagePushRequest available in a scratch org? (I don't see an obvious feature match in the Scratch Org Features list.) This question relates to Push upgrade app for second generation packages?.


When installing the Package Visualizer there is mention of a "Manage Billing" permission.

1 Answer 1


Push upgrades are used to "force" updates from a central location to some/all subscribers (hence the designation of "push," as in "to press against with force in order to drive or impel").

This technology has been an ISV feature for ages, where they would fix a critical bug in the "packaging org," then force an update for all subscribers without manual intervention. The feature you're asking about does the same thing, but for Unlocked Packages.

In this case, your Scratch Org would be classified as a "subscriber," and the Dev Hub org would be classified as the "packaging org." By using this feature, you cause the Dev Hub org to force an update to the subscriber by specifying the Scratch Org's SubscriberOrganizationKey in the PackagePushJob in the Dev Hub org.

Since Scratch Orgs cannot, by definition, be Dev Hub orgs, there's no way to create/enable those objects in a Scratch Org.

Edit: after reading the other question, I understand your intent. This would be something you'd have to use with pure Dynamic Apex if you wanted the resulting code to be a 2GP that one could install.

  • Thanks sfdcfox. If the code can only be run in certain orgs, maybe dynamic Apex with some mocking is the way to go to get a push upgrade app developed. Then final testing in an org that has the objects available.
    – Keith C
    Jun 19, 2021 at 17:00
  • 1
    @KeithC That's exactly where I was going with that.
    – sfdcfox
    Jun 19, 2021 at 17:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .