Patch Release
A Patch Release is a minor version of a Salesforce managed package that ships bug fixes and small enhancements without changing the package's major or minor version numbers.
Definition
A Patch Release is a minor version of a Salesforce managed package that ships bug fixes and small enhancements without changing the package's major or minor version numbers. The publisher builds it in a Patch Development Org seeded with the prior major version, makes only the metadata changes the patch namespace allows, uploads it, and then delivers it to every subscriber org through a Push Upgrade.
Patch Releases exist to give ISVs a safe path to ship a fix without forcing every customer to manually reinstall. The patch namespace forbids breaking changes by design: no Apex API signature changes, no field deletions, no required-field additions, no schema rearrangement that would invalidate existing subscriber data. What you can do is add Apex code, add new metadata, change existing Apex method bodies that do not change their public signatures, and fix flow or validation rule logic. The narrow scope is the price you pay for a feature that can update tens of thousands of subscriber orgs overnight.
What you can ship in a Patch Release and what waits for the next major
Patch numbering
A Patch Release uses the third position in a Salesforce package version (1.4.1, 1.4.2, ...). The first two positions (major.minor) come from the parent managed package; the patch number increments on each upload. Patch Releases stack: 1.4.5 includes everything from 1.4.1 through 1.4.4 plus the new changes. Salesforce keeps every uploaded patch available for install, so a subscriber on 1.4.1 can be pushed to 1.4.5 in one step or installed to any intermediate version manually.
Patch Development Org
Salesforce provisions a Patch Development Org (PDO) automatically when the publisher clicks New Patch in the Partner Business Org. The PDO is seeded with the prior major version and locked to the patch namespace constraints. Any DML or metadata change the publisher attempts that would break the constraint is blocked at save time, not at upload. This is the platform's primary defense against accidentally shipping a breaking patch.
What the patch namespace allows
Permitted changes include: adding new Apex classes and triggers, adding new custom objects and fields, changing the body of existing Apex methods (keeping the signature), adding new flow versions, changing validation rule formulas, updating static resources, updating Lightning component bundles, updating custom labels and translations. Disallowed changes include: deleting Apex classes, removing Apex methods, changing method signatures, removing custom fields, marking previously optional fields required, changing field types, removing components from the package.
Security review and pricing
Patch Releases skip the full AppExchange security review that major versions go through. Salesforce treats the constraint set as sufficient assurance that the patch will not introduce new attack surface. This is a real time savings: a major release security review can take 8 to 12 weeks, while a patch is uploaded and pushed in days. Patch Releases also do not change pricing or subscription terms; the patch inherits the parent version's commercial agreement with every subscriber.
Push Upgrade is the delivery channel
Once the patch is uploaded, the publisher uses the Subscriber Support Console to send it as a Push Upgrade. The patch lands in every selected subscriber org on the schedule the publisher picked. The relationship between the two features is intentional: patches are what Push Upgrades deliver, and Push Upgrades are how patches reach the install base without each admin running an install wizard. The publisher can also leave the patch as install-only (no push), letting subscribers self-upgrade through a regular install URL.
Beta patches for friendly testing
Before uploading a final patch, the publisher can upload a Beta patch from the PDO. Betas are time-limited (expire in 30 to 60 days), do not count toward the version sequence, and can be installed only manually (not via Push Upgrade). Most ISVs use beta patches to validate a fix with two or three friendly subscribers before promoting to a real patch. The beta version expires automatically, which is exactly the safety net you want for a fix you are not yet sure is correct.
When a fix does not fit in a Patch Release
Any change that breaks the patch namespace must wait for the next minor or major version. Common examples: removing a deprecated field, adding a required field, changing a method signature to take an additional parameter, removing a deprecated Apex class. The right pattern is to mark the old surface deprecated in a patch (which is allowed), document the replacement in release notes, then break it in the next major version with a clear migration guide. Customers who skip the deprecation cycle and try to break things in a patch find the upload blocked.
Build, upload, and ship a Patch Release
Spin up a Patch Development Org from your Partner Business Org, apply the fix, upload the patch, and ship it to subscribers via Push Upgrade.
- Click New Patch
From the package detail page in your Partner Business Org, click New Patch. Select the base major version you are patching. Salesforce provisions a Patch Development Org seeded with that version.
- Log into the PDO and apply the fix
The PDO has the package metadata pre-installed. Make only the changes the patch namespace permits. The platform blocks disallowed changes at save time.
- Run apex unit tests
Every patch must keep code coverage above 75 percent. Run Apex Tests in the PDO. Fix any test failures before upload, because security review will not run but the upload check still runs the tests.
- Optionally upload a Beta
For risky fixes, upload as Beta first. Install the beta into two or three friendly subscribers. Validate. The beta expires in 30 to 60 days; promote to a real patch when you are satisfied.
- Upload the final patch
Back in the Partner Business Org, click Upload on the patch version. Salesforce produces a new install URL and increments the patch number (1.4.2 to 1.4.3).
- Push to subscribers
Open the Subscriber Support Console. Schedule a Push Upgrade to a wave of subscribers (start small, expand). Monitor the console for failures.
Provisioned org locked to the patch namespace where the fix is built and tested.
Time-limited patch upload for friendly testing. Cannot be pushed; expires in 30 to 60 days.
The third position in the version number (1.4.X). Increments on each upload.
Delivery channel that lands the patch in every selected subscriber org automatically.
- The patch namespace blocks any change that would break compiled Apex or invalidate subscriber data. If your fix requires a field removal or a method signature change, plan for the next major version.
- Patch Releases skip security review but still require 75 percent code coverage at upload. Add tests for the fix before clicking Upload.
- Beta patches expire on their own. Do not build long-term subscriber relationships against a beta version; promote to a real patch before the expiration.
- Patches accumulate. A subscriber on 1.4.1 jumping to 1.4.7 gets every intermediate change rolled in. Test the cumulative effect, not just the single fix you wrote.
Trust & references
Cross-checked against the following references.
- Patch VersionsSalesforce Developer Docs
- Pushing an UpgradeSalesforce Developer Docs
- Salesforce Partner CommunitySalesforce Partner Program
Straight from the source - Salesforce's reference material on Patch Release.
- Patch Versions DocumentationSalesforce Developer Docs
- ISVforce Packaging GuideSalesforce Developer Docs
- Subscriber Support ConsoleSalesforce Developer Docs
Hands-on resources to go deeper on Patch Release.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Patch Release?
Q2. Can patches be pushed automatically?
Q3. When are patch releases valuable?
Discussion
Loading discussion…