Updated June 17, 2026 by Sunny Chauhan, Salesforce Platform Developer II.

Push upgrades have always been the publisher's escape hatch. A customer hasn't installed your latest version, you found a security issue, you push the patch to their org without asking. Useful, but blunt. The Summer '26 release adds a small but real refinement: push upgrade customization with an expiration window. You can configure the push to apply for a set number of days, then stop trying. It's the feature most ISVs don't know exists and the one we'll start recommending to anyone shipping seasonal-release fixes.

Pro Tip

TL;DR Salesforce Summer '26 lets ISVs configure push upgrades that expire after a set number of days. You create a PushUpgradeCustomizationRepository record in your 1GP packaging org or 2GP Dev Hub and specify the window. Useful when you want a push attempted but not retried forever, especially for seasonal-release compatibility fixes that lose relevance over time.

A standard push upgrade keeps trying. If a customer's org is locked, in maintenance, or fails the push for any other reason, Salesforce retries the upgrade until it succeeds or the customer manually upgrades. That's been the behavior since push upgrades shipped.

The Summer '26 feature changes that. You can now specify an expiration window in days. Once the window passes, Salesforce stops attempting the push. The customer either installed manually by then, or they didn't, and you're not retrying anymore.

The mechanism: a record in the new PushUpgradeCustomizationRepository object. You create the record in your 1GP packaging org or 2GP Dev Hub, set the expiration days, and the push upgrade you schedule respects that window.

Three scenarios where the expiration window earns its place:

→ Seasonal-release compatibility fixes. You ship a patch in May that fixes a Spring '26 compatibility issue. By August, the customer's org is on Summer '26 and the patch is irrelevant. You don't want Salesforce still trying to apply a Spring-era fix in October.

→ Time-sensitive security patches. The vulnerability is patched in your shipped version. Older versions are still vulnerable until the customer upgrades. After a window of (let's say) 30 days, the unpatched customers are either on the new version or they've ignored multiple notifications and you've moved them to a support workflow instead of retrying the push.

→ Trial-period auto-upgrades. You upgrade your trial customers automatically for the first 30 days of their trial, then stop. Lets them experience the latest version during evaluation without being on an auto-upgrade path forever.

For evergreen feature releases (not seasonal, not security), I'd stick with standard pushes. The expiration window is overhead for a case that doesn't need it.

You create a record in PushUpgradeCustomizationRepository with the parameters that govern the push. The relevant fields:

→ The package version you're pushing → The target subscriber orgs (all installed customers, a specific list, etc.) → The expiration window in days → The scheduled push date

The CLI invocation for creating the record looks like a standard metadata API call against your packaging org or Dev Hub. Salesforce's documentation has the exact field list. The setup itself takes about 10 minutes once you've understood the model.

The push upgrade then runs the same way standard pushes run, with the added constraint that retries stop after the configured window.

The customization doesn't change what a push upgrade is. It's still the publisher applying a new version to a customer's org without their explicit action. Customers still can't decline (push upgrades are mandatory by design). The customization only affects how long Salesforce keeps trying.

If you're hoping for push upgrades that respect customer maintenance windows, customer-initiated retries, or anything resembling a customer-side approval flow, this isn't that. The push model stays the same. The expiration is an upper bound on retry persistence.

Appnigma generates 2GP Managed Packages and handles the package version creation, but push upgrade orchestration is still ISV-side operational work. You decide when to push, which customers, and (with Summer '26) what expiration window. We surface the controls; the policy decision stays yours.

For most no-code-generated packages, push upgrades become more common because the generation workflow lets you ship patches quickly. The expiration window is a useful pairing: ship the fix, push it for 30 days, then stop. Cleaner than running an unbounded retry loop.

• [ ] Decided which scenario justifies the expiration window → Yes / No

• [ ] Created the PushUpgradeCustomizationRepository record with the right window → Yes / No

• [ ] Tested the push in a sandbox customer org first → Yes / No

• [ ] Communicated the push timing to customers (email or in-app notification) → Yes / No

• [ ] Confirmed the push date and time don't collide with major customer-side change windows → Yes / No

• [ ] Set up monitoring for push success rate during the window → Yes / No

• [ ] Defined a fallback for customers who don't upgrade by expiration → Yes / No

In April 2026 you ship a patch to your Managed Package that fixes a Spring '26 compatibility issue. 60% of your customers upgrade through their normal install flow within two weeks. The other 40% are slower. You schedule a push upgrade with a 60-day window.

Days 1 through 14: most of the unpatched 40% receive the push successfully. Salesforce retries any that failed.

Days 15 through 45: continued retries for the holdouts (customer orgs locked, in maintenance, etc.). Salesforce keeps trying.

Day 60: the expiration window passes. Salesforce stops attempting. Any remaining unpatched customers (maybe 1 to 2% of your install base) get a support flag and an email asking them to manually upgrade.

By August, you're not still pushing a Spring-era fix. The window did its job.

A Salesforce feature GA'd in the Summer '26 release that lets ISVs configure push upgrades to expire after a set number of days. ISVs create a PushUpgradeCustomizationRepository record in their 1GP packaging org or 2GP Dev Hub and specify the window. Once the window passes, Salesforce stops attempting the push (Salesforce Summer '26 release notes).

Yes, both. For 1GP, create the PushUpgradeCustomizationRepository record in your packaging org. For 2GP, create it in your Dev Hub. The expiration window applies the same way.

No. Push upgrades are mandatory by design. The customization only affects how long Salesforce retries, not whether the customer can opt out. See our guide on managing package upgrades for the difference between push and install upgrades.

After the window expires, Salesforce stops attempting. Customers who didn't receive the push remain on their existing version. Most ISVs set up a support workflow at expiration: email the holdouts, flag them in the CRM, and route them to manual upgrade.

No. The Security Review reviews the package version itself, not the upgrade configuration. Standard $999 per submission for paid apps.

Less useful. For feature releases without time-sensitivity, standard push upgrades work fine. The expiration window earns its place when the patch loses relevance over time (seasonal-release fixes, time-bounded security patches, trial-period auto-upgrades).

Sunny Chauhan is the founder and CEO of Appnigma AI, a no-code platform that generates Salesforce AppExchange-ready Managed Packages from natural-language prompts. He holds Salesforce certifications in Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate. Since launching Appnigma in 2024, his team has helped B2B SaaS companies including Warmly, Hyperbound, Pylon, Seam AI, and Avoma ship and maintain native Managed Packages.

Originally published June 17, 2026. Last reviewed June 17, 2026. Feature details verified against the Salesforce Summer '26 release notes and ISV strategy blog current as of the published date.

• How to upgrade a managed package in Salesforce

• Salesforce Managed Package: Complete Guide (1GP vs 2GP)

• 1GP to 2GP managed package migration

• Salesforce security review

• How to build a managed package without a Salesforce developer

• Salesforce app development cost

1/ Salesforce Summer '26 Release Notes 2/ Salesforce blog, ISV Strategy for the Summer '26 Release 3/ Aquiva Labs, Summer '26 Salesforce Release Highlights 4/ Salesforce Ben, Summer '26 Release coverage

What's the last push upgrade you scheduled, and how long did you actually want Salesforce to keep retrying?