One or more of the listed organizations is on a version incompatible with this change set

May 22, 2013

This post describes an issue and the solution to an error received when trying to push a sandbox between Salesforce environments that are of different releases/versions (eg Spring13 vs. Summer13). The solution was provided by Salesforce support.

Problem: If a sandbox has been upgraded to a new Salesforce release and the Production environment has not. When attempting to upload the change sets to production (or another sandbox) you may see this error message:

“This change set requires the “28.0” or later platform version. One or more of the listed organizations is on a version incompatible with this change set. You can only select an organization for upload that is running the required version or later.”

Reason this occurs: The target org is selected the first time a user uploads a change set. Based on the target org, Salesforce sets the version of the change set (current release vs next release) to match the target org’s version. Once this is done, Salesforce requires that subsequent uploads of that change set be targeted to other orgs on the same version, or a later (newer) version, used in the original upload.

Scenario 1 :

Change Set “A” is created in a Winter ’13 org
• The first upload attempt of Change Set “A” targets a Winter ’13 org and is successful
• A second upload attempt of Change Set “A” targets a Spring ’13 org and is successful
• Both attempts were successful since the first upload attempt locked the change set to Winter ’13. Subsequent upload attempts of the original change set must be targeted to other Winter ’13 or Spring ’13 orgs based on the “Reason this occurs:” wording above.

Scenario 2:

• Change Set “A” is created in a Winter ’13 org
• The first upload attempt of Change Set “A” targets a Spring ’13 org and is successful
• A second upload attempt of Change Set “A” targets a Winter ’13 org and hits the error
• It’s expected that the second upload failed since the first upload targeted a Spring ’13 org. Subsequent upload attempts of the original change set must be targeted to other Spring ’13 orgs based on the “Reason this occurs:” wording above.

Workaround for Scenario 2:

• Clone Change Set “A”
• Upload of the cloned change set to a Winter ’13 org (Scenarion 2 above) is successful
• Why does the act of cloning the change set resolve the issue? A cloned change set is treated as a new change set. Since it has yet to be uploaded to an org, it’s version hasn’t been locked (as described in “Reason this occurs:” above). Therefore, it can be uploaded to a current version or a Preview sandbox.

Solution: In short; if you find your self moving change sets between different environments after a sandbox upgrade you may need to upload te change set to a sandbox that hasn’t yet been upgraded or to production to lock in the API version of the change set.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

<span>%d</span> bloggers like this: